From nobody Fri May 1 01:47:36 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840193A0C86 for ; Fri, 1 May 2020 01:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvWuzsJhLbfz for ; Fri, 1 May 2020 01:47:31 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5AA3A0C7C for ; Fri, 1 May 2020 01:47:25 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d05 with ME id ZLnJ2200Q4FMSmm03LnMWt; Fri, 01 May 2020 10:47:23 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 01 May 2020 10:47:23 +0200 X-ME-IP: 86.238.65.197 To: oauth@ietf.org References: From: Denis Message-ID: <27491ba3-857d-8ab9-fbe3-f3cf37d0078b@free.fr> Date: Fri, 1 May 2020 10:47:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------28178BA488F52192CAFE41F4" Content-Language: en-GB Archived-At: Subject: [OAUTH-WG] DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 08:47:34 -0000 This is a multi-part message in MIME format. --------------28178BA488F52192CAFE41F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Comments on draft-ietf-oauth-dpop-00. 1) In section 9 (Security considerations), the text states: DPoP does not, however, achieve the same level of protection as TLS-based methods such as OAuth Mutual TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding] (see also Section 9.1 and Section 9.4). draft-ietf-oauth-token-binding-08 [i.e. I-D.ietf-oauth-token-binding] expired on April 22, 2019, thus it does not seem adequate to refer to it. 2)  The text states: 9.1.DPoP Proof Replay If an adversary is able to get hold of a DPoP proof JWT, the adversary could replay that token at the same endpoint (the HTTP endpoint and method are enforced via the respective claims in the JWTs). This is true, but there is a worse case:  if a client legitimately obtains a DPoP proof JWT and collaborates with another client, then it can provide it to that other client. 3)  The text states:    9.4.Message Integrity DPoP does not ensure the integrity of the payload or headers of requests.The signature of DPoP proofs only contains the HTTP URI and method, but not, for example, the message body or other request headers. This is an intentional design decision to keep DPoP simple to use, but as described, makes DPoP potentially susceptible to replay attacks where an attacker is able to modify message contents and headers.In many setups, the message integrity and confidentiality provided by TLS is sufficient to provide a good level of protection. DPoP alone or DPoP used in conjunction with TLS does not provide any protection in case of collusion attacks between collaborative clients. Collaborative attacks between clients cannot be countered using software-only implementations. It should also be noticed that the use of secure elements to only protect private keys is insufficient, since a collaborative client can still perform all the cryptographic computations needed by the other client. These considerations aboutcollaborative clients should be added into the security considerations section. Denis --------------28178BA488F52192CAFE41F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Comments on draft-ietf-oauth-dpop-00.

1) In section 9 (Security considerations), the text states:

        DPoP does not, however, achieve the
   same level of protection as TLS-based methods such as OAuth Mutual
   TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding]
   (see also Section 9.1 and Section 9.4).

draft-ietf-oauth-token-binding-08 [i.e. I-D.ietf-oauth-token-binding] expired on April 22, 2019,
thus it does not seem adequate to refer to it.

2)  The text states:

        9.1.  DPoP Proof Replay

   If an adversary is able to get hold of a DPoP proof JWT, the
   adversary could replay that token at the same endpoint (the HTTP
   endpoint and method are enforced via the respective claims in the
   JWTs).

This is true, but there is a worse case:  if a client legitimately obtains a DPoP proof JWT and collaborates
with another client, then it can provide it to that other client.

3)  The text states:

   9.4.  Message Integrity

   DPoP does not ensure the integrity of the payload or headers of
   requests.  The signature of DPoP proofs only contains the HTTP URI
   and method, but not, for example, the message body or other request
   headers.

   This is an intentional design decision to keep DPoP simple to use,
   but as described, makes DPoP potentially susceptible to replay
   attacks where an attacker is able to modify message contents and
   headers.  In many setups, the message integrity and confidentiality
   provided by TLS is sufficient to provide a good level of protection.

DPoP alone or DPoP used in conjunction with TLS does not provide any protection in case of collusion attacks
between collaborative clients.

Collaborative attacks between clients cannot be countered using software-only implementations.
It should also be noticed that the use of secure elements to only protect private keys is insufficient,
since a collaborative client can still perform all the cryptographic computations needed by the other client.

These considerations about collaborative clients should be added into the security considerations section.

Denis

--------------28178BA488F52192CAFE41F4-- From nobody Fri May 1 02:37:14 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD673A0D80 for ; Fri, 1 May 2020 02:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRYd4IK0vRzm for ; Fri, 1 May 2020 02:37:07 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51833A0D6E for ; Fri, 1 May 2020 02:37:06 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id t8so3569651uap.3 for ; Fri, 01 May 2020 02:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HaWojZ154ty1BuXuO0+YO3eSKuA4lL2H6ORoaKrmkaI=; b=5awIM4iy4PfIWH8iLvP2aZ1BguuIoFxQNnU9m4l48MLuUcP9lQbPr644tU5GXS8Il7 kDxPQWCHUPbildXKpAgsOuC5kQAqu3ZJPt6thfGsRSVBKeQqMUbutWiQzvagCIUOZ0HE Fd/t/Q+2Jy+PsIuy5mpLk+z5HpTEbm1kuB9vXAVm0y2y27K2obCIkW4DJicDwVwqH2CG A0iUHZ3YZ7y8fNd0RSzWkV92BHN1ykO4Nefu8rcvZwI+3EFJIRi0pZrsdrcbX+aM1iTC xf8iF4Ly81EF52YDH+fbKwIJIIgChDNX/QK+0sTUG0fH9g0K5cruf7LwrXoGDSrCg0zU LSRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HaWojZ154ty1BuXuO0+YO3eSKuA4lL2H6ORoaKrmkaI=; b=YTbplIPX9t9T4J+OFWjD0EHSCeJ223P0UJhezNAPXhEMT7NTAH1OYB5xy/2/bqDtqo gU5qnU6fpQ2N0TJ+y6Byj78OZN9RDRsMJrhVwxmsEjNWazZ6ucl0/cZM9kL9KhycPhs3 oONDJ4RxooHVa4ulLugyAu0odEVogN/RpuJYRz+rDhgD1a0olegvaypyvawEoajf01UN vTzcmRfxgwGSDUTzjsGtBqbziVx6RwavF671UeBtwlzfXR2fQd0M3WkGtiGQJ0OgOlwu R8MYXYfJA4hb0SG/B0y7P23jutPZqDd5keQgdrMTY5LbENpZlT3luJdPDiZLNVaViExc jHGA== X-Gm-Message-State: AGi0PuZrnTdMrpOgnuKpgn448MTPBG80j32DlnHzpC4TCi2zmJlja3Rt hgm4Iky4jwfCKHhHVSneWZHFp0bO3D31t50WcH0WqA== X-Google-Smtp-Source: APiQypIhIT/d5FvU1K0QjMbRnVGxylzeW3doPcc0hM4c3MdSwvAgLYCKVbV2AHXQcPi3pw4+MojrSofdufrNfPlNcBA= X-Received: by 2002:ab0:4ac9:: with SMTP id t9mr2241797uae.40.1588325825619; Fri, 01 May 2020 02:37:05 -0700 (PDT) MIME-Version: 1.0 References: <88d7c433-bd4b-456a-bc04-d30ed988fe9f@Spark> In-Reply-To: From: Torsten Lodderstedt Date: Fri, 1 May 2020 11:36:54 +0200 Message-ID: To: Mike Jones Cc: John Bradley , Nat Sakimura , oauth Content-Type: multipart/alternative; boundary="0000000000009fc14705a492ece0" Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: I-D Action: draft-ietf-oauth-jwsreq-21.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 09:37:12 -0000 --0000000000009fc14705a492ece0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Mike. I suggest to add text to JAR describing use of this registry values to determine the request object signing and encryption algorithms. Mike Jones schrieb am Mi. 29. Apr. 2020 um 01:38: > =E2=80=9Crequest_object_signing_alg_values_supported=E2=80=9D and other A= S Metadata values > defined by OpenID Connect Discovery are now registered at > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#= authorization-server-metadata > . > > > > -- Mike > > > > *From:* nat=3Dsakimura.org@mg.sakimura.org > *On Behalf Of *Nat Sakimura > *Sent:* Sunday, April 26, 2020 10:29 AM > *To:* Torsten Lodderstedt ; > John Bradley ; Mike Jones < > Michael.Jones@microsoft.com> > *Cc:* oauth > *Subject:* [EXTERNAL] Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-jwsreq-21.txt > > > > Thanks Mike. > > > > Right in as much as I never expected JAR to take this long, I was > expecting the errata to be published and these params to be registered lo= ng > before as well :-) But it may be a good sign that we Identiterati are all > so busy these days. > > > > Nat Sakimura > > Chairman, OpenID Foundation > > https://nat.sakimura.org > > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5 2:17 +0900=E3=80=81Mike Jones =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > The next errata version of OpenID Connect Discovery will register the > parameter request_object_signing_alg_values_supported and other parameter= s > not previously registered. See > https://openid.net/specs/openid-connect-discovery-1_0-29.html for the > latest published errata draft. > > I can make a request for early registration if it would be useful. > > -- Mike > > -----Original Message----- > From: OAuth On Behalf Of Torsten Lodderstedt > Sent: Sunday, April 26, 2020 8:17 AM > To: Nat Sakimura ; John Bradley > Cc: oauth > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt > > Hi Nat & John, > > I tried to find out how signing & encryption algorithms are determined in > the JAR context. > > I just found this note in the history for -07: "Stopped talking about > request_object_signing_alg=E2=80=9D > > I assume you assume this is done via client registration parameters > registered in > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#= client-metadata? > Why doesn=E2=80=99t JAR state so? > > What is about algorithms supported by the AS? The respective parameters, > such as request_object_signing_alg_values_supported are not registered ye= t > in > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#= authorization-server-metadata > . > > best regards, > Torsten. > > > > On 19. Apr 2020, at 20:30, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization > Request (JAR) > Authors : Nat Sakimura > John Bradley > Filename : draft-ietf-oauth-jwsreq-21.txt > Pages : 31 > Date : 2020-04-19 > > Abstract: > The authorization request in OAuth 2.0 described in RFC 6749 utilizes > query parameter serialization, which means that Authorization Request > parameters are encoded in the URI of the request and sent through > user agents such as web browsers. While it is easy to implement, it > means that (a) the communication through the user agents are not > integrity protected and thus the parameters can be tainted, and (b) > the source of the communication is not authenticated. Because of > these weaknesses, several attacks to the protocol have now been put > forward. > > This document introduces the ability to send request parameters in a > JSON Web Token (JWT) instead, which allows the request to be signed > with JSON Web Signature (JWS) and encrypted with JSON Web Encryption > (JWE) so that the integrity, source authentication and > confidentiality property of the Authorization Request is attained. > The request can be sent by value or by reference. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-21 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000009fc14705a492ece0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mike.

I suggest to add text to JAR describing use of this registry va= lues to determine the request object signing and encryption algorithms.=C2= =A0

Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> schrieb am Mi.= 29. Apr. 2020 um 01:38:

=E2=80=9Crequest_= object_signing_alg_values_supported=E2=80=9D and other AS Metadata values d= efined by OpenID Connect Discovery are now registered at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#au= thorization-server-metadata.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<= /u>

From: nat=3Dsakimura.org@mg.sakimura.org <nat= =3Dsakimu= ra.org@mg.sakimura.org> On Behalf Of Nat Sakimura
Sent: Sunday, April 26, 2020 10:29 AM
To: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>; John Bradley <jbradley@yubico.com>; Mike Jones <Michael.Jones@microsoft.com>=
Cc: oauth <oa= uth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsr= eq-21.txt

=C2=A0

Thanks Mike.=C2=A0

=C2=A0

Right in as much as I never expected JAR to take thi= s long, I was expecting the errata to be published and these params to be r= egistered long before as well :-) But it may be a good sign that we Identit= erati are all so busy these days.=C2=A0

=C2=A0

Nat Sakimura=C2=A0

Chairman, OpenID Foundation=C2=A0

2020=E6=9C= =8827=E6=97=A5 2:17 +0900=E3=80=81Mike Jones <Michael.Jones@microsoft.com> =E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:

The next errata version of OpenID Connect Discovery = will register the parameter request_object_signing_alg_values_supported and= other parameters not previously registered. See https://openid.net/specs/openid-connect-discovery-1_0-29.h= tml for the latest published errata draft.

I can make a request for early registration if it would be useful.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
Sent: Sunday, April 26, 2020 8:17 AM
To: Nat Sakimura <= nat@sakimura.org>; John Bradley <jbradley@yubico.com>
Cc: oauth <oauth@iet= f.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt

Hi Nat & John,

I tried to find out how signing & encryption algorithms are determined = in the JAR context.

I just found this note in the history for -07: "Stopped talking about = request_object_signing_alg=E2=80=9D

I assume you assume this is done via client registration parameters registe= red in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#cl= ient-metadata? Why doesn=E2=80=99t JAR state so?

What is about algorithms supported by the AS? The respective parameters, su= ch as request_object_signing_alg_values_supported are not registered yet in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#au= thorization-server-metadata.

best regards,
Torsten.



On 19. Apr 2020, at 20:30, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Re= quest (JAR)
Authors : Nat Sakimura
John Bradley
Filename : draft-ietf-oauth-jwsreq-21.txt
Pages : 31
Date : 2020-04-19

Abstract:
The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of
these weaknesses, several attacks to the protocol have now been put
forward.

This document introduces the ability to send request parameters in a
JSON Web Token (JWT) instead, which allows the request to be signed
with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
(JWE) so that the integrity, source authentication and
confidentiality property of the Authorization Request is attained.
The request can be sent by value or by reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/<= br>
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-= jwsreq-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsr= eq-21


Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.

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


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


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

--0000000000009fc14705a492ece0-- From nobody Fri May 1 02:49:27 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE153A0D76 for ; Fri, 1 May 2020 02:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtxtpLurfM7h for ; Fri, 1 May 2020 02:49:23 -0700 (PDT) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E826C3A0D74 for ; Fri, 1 May 2020 02:49:22 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id 10so2576516vkr.7 for ; Fri, 01 May 2020 02:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HUbOeFAzPPIU0nl758HZ6ElbP4Te0GZHHmU+EdT101w=; b=04mTdpKf5vnLyzGOcirLZiIa+OL6ShD5pkoN+YpM/8zcy4+mqI427y630dVgQCyFa4 7+nH9lN7FQ4VkXiYHaQfiEo4pGrtu0PH0PrylwqQwdoJAHcZduQLpUB4sabl68WBFilJ hAICFK9AMs2wsXrNNXNLprMX1aB9kt3PatUlIFm7TD2j3mh3RBPbzp4GMUj1A3k++I6R uSaYVDMmfQ1u9Qi2PrLqHrWefRiR5iDdpqXxQ3e7Nj8p2q6G4GevU3Rb+hz8XxboxGbU IA0Dig0HAaFmtJrWoMuwZgWZAuoYpIekW1dAc7XuythRl2USZCTXrZqaUF99WZP6q5Ve Hq5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HUbOeFAzPPIU0nl758HZ6ElbP4Te0GZHHmU+EdT101w=; b=kqtZEgpXKMkUdIN9H2EMOSkDdNYPNk8U1Fxxt+HxWbiwbjj730xHRnIRNpULxii8c5 h1PhzH6M9z2Sc7r6f4m4zXsg9i0CewoUFlsEisXSFKnlyZQRkEOzST1KJAYQD9WcJdgN 2CYRpR2aHQO0Axng5KWvGjWHjTE48QV1GQfUpJvH0fTG08bUa1FQpBB6XkGrReEV9Tss UJvFh+/IckAt53WZ1PBhP1qdrLu8sMkuSaJw/afFRTVUQO7rnugknbYtxYzwR8Ifxu6j Cbm7zWY21FX4AzahcmpMvjsj7k27xMbLIjKWBgE/ejLyZnyITi4/PAeHcUyNGWxCmDnK vxcA== X-Gm-Message-State: AGi0PuZ6TkUs5jCCvnT4Ir6EWjYoVNU+njkMRs4AQc4Akotn3M4XUKKQ hnQZXBZ4HBMHqdgRe8wyYA0irCNfeMJ7WIruf6MTuQ== X-Google-Smtp-Source: APiQypK3tqz5/WmH6BGny6zWJZYD2N2pzYxi6rtu1nqso9XJWF0lzz/85McJwStb5gNFidJMSmVW2Q9xRloqiwFde4A= X-Received: by 2002:a1f:a786:: with SMTP id q128mr2113408vke.86.1588326561729; Fri, 01 May 2020 02:49:21 -0700 (PDT) MIME-Version: 1.0 References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com> <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com> In-Reply-To: From: Torsten Lodderstedt Date: Fri, 1 May 2020 11:49:10 +0200 Message-ID: To: Brian Campbell Cc: Filip Skokan , oauth Content-Type: multipart/alternative; boundary="0000000000007fe2c105a49318bc" Archived-At: Subject: Re: [OAUTH-WG] PAR and client metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 09:49:25 -0000 --0000000000007fe2c105a49318bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable wfm - thanks. Brian Campbell schrieb am M= o. 27. Apr. 2020 um 21:06: > require_pushed_authorization_requests works for me and is maybe/arguably = a > bit better by being more consistent with other names. > > On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan wrote: > >> Alternatively, `require_pushed_authorization_requests`. Since we already >> have the `*require_*request_uri_registration` server and `*require_* >> auth_time` client metadata properties. >> >> WDYT? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt > 40lodderstedt.net@dmarc.ietf.org> wrote: >> > Hi all, >>> >>> I think this topic has several aspects: >>> - Is the client required to use PAR only? Doesn=E2=80=99t this also mea= n it is >>> required to use request_uri only? >>> - Is there a need to separate those to questions or shall we treat this >>> as the same? >>> - Who decides whether PAR and request_uri are required? The client for >>> its instances or the AS for the whole deployment? >>> >>> I=E2=80=99m in favour of coupling enforced PAR use with enforced reques= t_uri use >>> even though it means the setting is useful with PAR only, not with all >>> JAR-based clients. >>> I think both the client as well as the AS should be able to declare >>> forced PAR. If the AS is able to basically turn of traditional >>> authorization requests, it can consequently utilize the changed protoco= l >>> properties in terms of security and robustness in its deployment. This >>> means, for example, the AS no longer needs to require pre-registered >>> redirect URIs for confidential clients. It also means, the AS can use >>> voluminous claims/authorization details objects without worrying about >>> fragile long request URLs. >>> >>> So here is my proposal: >>> >>> 1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests= _only=E2=80=9D of >>> type boolean - It requires any client to use PAR, the AS will refuse to >>> process any authorization request containing parameters other than >>> request_uri + client_id (as required by >>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension >>> request parameters need to be passed via PAR. >>> 2) Add client registration parameter >>> =E2=80=9Cpushed_authorization_requests_only=E2=80=9D - It requires this= client to use PAR >>> only. The AS won=E2=80=99t accept any authorization request containing = more than >>> request_uri + client_id for that particular client. >>> >>> What are your thoughts? >>> >>> best regards, >>> Torsten. >>> >>> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov >>> wrote: >>> > >>> > In a off-list conversation Torsten floated the idea of letting >>> confidential PAR-only clients register without a redirect_uris and havi= ng >>> this "PAR only" parameter will enable that. >>> > >>> > A "PAR only" parameter will also prevent client developers from >>> accidentally making plain authz requests (for clients that rely on PAR = for >>> the extra security). >>> > >>> > Vladimir >>> > >>> > On 16/04/2020 18:39, Brian Campbell wrote: >>> >> >>> >> >>> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org> wrote: >>> >> As I think through this, I=E2=80=99m struggling to identify the thre= ats this >>> actually helps mitigate. >>> >> >>> >> A client metadata parameter implies that the value may be different >>> for different clients, and that any given client won=E2=80=99t already = know via >>> other means whether or not it needs to use PAR. That means we=E2=80=99r= e only >>> talking about dynamic clients since statically registered clients alrea= dy >>> have some proprietary out-of-band registration mechanism (e.g., a devel= oper >>> console). >>> >> >>> >> As I tried to articulate in the original email and Filip also >>> mentioned in a different fork of this email thread, defining metadata c= an >>> be beneficial even when it's not used dynamically at runtime. So we're = not >>> only talking about dynamic clients. >>> >> >>> >> >>> >> >>> >> A client metadata parameter also implies that the AS allows some >>> clients to make non-PAR requests (otherwise it would be an AS metadata >>> parameter). >>> >> >>> >> A per client setting seems necessary for existing ASs to roll out PA= R >>> support over time or just generally in support of diverse client >>> capabilities and requirements. >>> >> >>> >> >>> >> If that=E2=80=99s the case then presumably a malicious party could r= egister >>> their own client that doesn=E2=80=99t use PAR. >>> >> >>> >> So it seems to me that the only scenario that this parameter would >>> protect against is a malicious party impersonating a dynamically regist= ered >>> client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in t= hat attack >>> the attacker uses its own client. >>> >> >>> >> This client metadata parameter is meant to be something that would >>> prevent a malicious actor from controlling the content of the authz req= uest >>> parameters, which could be done by crafting the link and tricking a use= r >>> into following it. I mentioned mix-up as an example because the first >>> variant of it desribed at >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section= -4.4.1 >>> does something along those lines. >>> >> >>> >> >>> >> >>> >> If a client can do PAR, then it can do authorization code grant and >>> PKCE, so we=E2=80=99re further limited to scenarios where the attacker = does not >>> need to be able to redeem the authorization code themselves. What threa= ts >>> fall into this category? >>> >> >>> >> =E2=80=94 >>> >> Annabelle Backman (she/her) >>> >> AWS Identity >>> >> >>> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote: >>> >>> >>> >>> =EF=BB=BF >>> >>> CAUTION: This email originated from outside of the organization. Do >>> not click links or open attachments unless you can confirm the sender a= nd >>> know the content is safe. >>> >>> >>> >>> >>> >>> I was hoping to get to a rough consensus in support of the idea >>> before coming up with a name that everyone will hate :) >>> >>> >>> >>> In the meantime, however, name suggestions are of course welcome. >>> >>> >>> >>> >>> >>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov < >>> vladimir@connect2id.com> wrote: >>> >>> I'm all for that. >>> >>> >>> >>> I suppose you have already thought of a suitable name? :) >>> >>> >>> >>> Vladimir >>> >>> >>> >>> On 14/04/2020 23:08, Brian Campbell wrote: >>> >>>> Using PAR can facilitate improved security by giving clients a >>> (relatively) simple means for sending a confidential, integrity protect= ed, >>> and (for confidential clients anyway) authenticated authorization reque= st. >>> >>>> >>> >>>> It seems like some of that improved security could be undermined b= y >>> a malicious actor somehow getting a user to navigate to a URL of a regu= lar >>> old parameterized authorization request. One variation of the Mix-Up At= tack >>> does this >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section= -4.4.1 >>> for example and email, social media, online forums, etc., are other way= s a >>> user might be tricked into following a maliciously crafted link. >>> >>>> >>> >>>> Following from that it seems logical that an authorization server >>> might want to restrict some clients from sending a regular parameterize= d >>> authorization request and instead require use of the PAR endpoint to >>> initiate an authorization request. Something like this could, of course= , be >>> implemented as custom policy or configuration in any AS. But I'm thinki= ng >>> it might be common enough to warrant adding a client metadata parameter= to >>> the PAR draft specifically for it. The metadata (and registered extensi= ons) >>> defined by Dynamic Client Registration [RFC7591] has come to imply a >>> general data model and expected associated behaviors for clients that i= s >>> useful for authorization server implementations, even when the Dynamic >>> Client Registration Protocol isn't directly in play. This particular >>> situation seems like a good potential candidate for a new such client >>> metadata parameter that would indicate that the given client can only u= se a >>> request_uri value obtained from the PAR endpoint to initiate an >>> authorization request. And that a regular old fashioned authorization >>> request from the given client would result in an error. >>> >>>> >>> >>>> Do the folks of this fine WG think something like this would be a >>> worthwhile addition to the PAR draft? >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly >>> prohibited.... If you have received this communication in error, pleas= e >>> notify the sender immediately by e-mail and delete the message and any = file >>> attachments from your computer. Thank you. >>> >>>> >>> >>>> _______________________________________________ >>> >>>> OAuth mailing list >>> >>>> >>> >>>> OAuth@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf...org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you. >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf...org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > > >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --0000000000007fe2c105a49318bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
wfm - thanks.


Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = schrieb am Mo. 27. Apr. 2020 um 21:06:
require_pushed_authorization_requests works for me and= is maybe/arguably a bit better by being more consistent with other names. = =C2=A0

On Mon, Apr 27, 2020 at 12:58 P= M Filip Skokan <= panva.ip@gmail.com> wrote:
Alternatively, `require_= pushed_authorizat= ion_requests`. Since we already have the `require_request_uri_registration` server and `require_auth_time` client metadata properties= .

WDYT?

S pozdravem,
Filip Skokan


On Sun, 26 Apr 202= 0 at 16:58, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
=
Hi all,

I think this topic has several aspects:
- Is the client required to use PAR only? Doesn=E2=80=99t this also mean it= is required to use request_uri only?
- Is there a need to separate those to questions or shall we treat this as = the same?
- Who decides whether PAR and request_uri are required? The client for its = instances or the AS for the whole deployment?

I=E2=80=99m in favour of coupling enforced PAR use with enforced request_ur= i use even though it means the setting is useful with PAR only, not with al= l JAR-based clients.
I think both the client as well as the AS should be able to declare forced = PAR. If the AS is able to basically turn of traditional authorization reque= sts, it can consequently utilize the changed protocol properties in terms o= f security and robustness in its deployment. This means, for example, the A= S no longer needs to require pre-registered redirect URIs for confidential = clients. It also means, the AS can use voluminous claims/authorization deta= ils objects without worrying about fragile long request URLs.=C2=A0

So here is my proposal:

1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests_onl= y=E2=80=9D of type boolean - It requires any client to use PAR, the AS will= refuse to process any authorization request containing parameters other th= an request_uri + client_id (as required by htt= ps://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension request= parameters need to be passed via PAR.
2) Add client registration parameter =E2=80=9Cpushed_authorization_requests= _only=E2=80=9D - It requires this client to use PAR only. The AS won=E2=80= =99t accept any authorization request containing more than request_uri + cl= ient_id for that particular client.

What are your thoughts?

best regards,
Torsten.

> On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov <vladimir@connect2id.com> wr= ote:
>
> In a off-list conversation Torsten floated the idea of letting confide= ntial PAR-only clients register without a redirect_uris and having this &qu= ot;PAR only" parameter will enable that.
>
> A "PAR only" parameter will also prevent client developers f= rom accidentally making plain authz requests (for clients that rely on PAR = for the extra security).
>
> Vladimir
>
> On 16/04/2020 18:39, Brian Campbell wrote:
>>
>>
>> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle <ric= hanna=3D40= amazon.com@dmarc.ietf.org> wrote:
>> As I think through this, I=E2=80=99m struggling to identify the th= reats this actually helps mitigate.
>>
>> A client metadata parameter implies that the value may be differen= t for different clients, and that any given client won=E2=80=99t already kn= ow via other means whether or not it needs to use PAR. That means we=E2=80= =99re only talking about dynamic clients since statically registered client= s already have some proprietary out-of-band registration mechanism (e.g., a= developer console).
>>
>> As I tried to articulate in the original email and Filip also ment= ioned in a different fork of this email thread, defining metadata can be be= neficial even when it's not used dynamically at runtime. So we're n= ot only talking about dynamic clients.
>>
>>=C2=A0
>>
>> A client metadata parameter also implies that the AS allows some c= lients to make non-PAR requests (otherwise it would be an AS metadata param= eter).
>>
>> A per client setting seems necessary for existing ASs to roll out = PAR support over time or just generally in support of diverse client capabi= lities and requirements.
>>
>>=C2=A0
>> If that=E2=80=99s the case then presumably a malicious party could= register their own client that doesn=E2=80=99t use PAR.
>>
>> So it seems to me that the only scenario that this parameter would= protect against is a malicious party impersonating a dynamically registere= d client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in tha= t attack the attacker uses its own client.
>>
>> This client metadata parameter is meant to be something that would= prevent a malicious actor from controlling the content of the authz reques= t parameters, which could be done by crafting the link and tricking a user = into following it. I mentioned mix-up as an example because the first varia= nt of it desribed at ht= tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1= does something along those lines.
>>
>>=C2=A0
>>
>> If a client can do PAR, then it can do authorization code grant an= d PKCE, so we=E2=80=99re further limited to scenarios where the attacker do= es not need to be able to redeem the authorization code themselves. What th= reats fall into this category?
>>
>> =E2=80=94
>> Annabelle Backman (she/her)
>> AWS Identity
>>
>>> On Apr 14, 2020, at 2:44 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>>> =EF=BB=BF
>>> CAUTION: This email originated from outside of the organizatio= n. Do not click links or open attachments unless you can confirm the sender= and know the content is safe.
>>>
>>>
>>> I was hoping to get to a rough consensus in support of the ide= a before coming up with a name that everyone will hate :)
>>>
>>> In the meantime, however, name suggestions are of course welco= me.
>>>
>>>
>>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <vladimir@connect2id.c= om> wrote:
>>> I'm all for that.
>>>
>>> I suppose you have already thought of a suitable name? :)
>>>
>>> Vladimir
>>>
>>> On 14/04/2020 23:08, Brian Campbell wrote:
>>>> Using PAR can facilitate improved security by giving clien= ts a (relatively) simple means for sending a confidential, integrity protec= ted, and (for confidential clients anyway) authenticated authorization requ= est.
>>>>
>>>> It seems like some of that improved security could be unde= rmined by a malicious actor somehow getting a user to navigate to a URL of = a regular old parameterized authorization request. One variation of the Mix= -Up Attack does this ht= tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1= for example and email, social media, online forums, etc., are other wa= ys a user might be tricked into following a maliciously crafted link.
>>>>
>>>> Following from that it seems logical that an authorization= server might want to restrict some clients from sending a regular paramete= rized authorization request and instead require use of the PAR endpoint to = initiate an authorization request. Something like this could, of course, be= implemented as custom policy or configuration in any AS. But I'm think= ing it might be common enough to warrant adding a client metadata parameter= to the PAR draft specifically for it. The metadata (and registered extensi= ons) defined by Dynamic Client Registration [RFC7591] has come to imply a g= eneral data model and expected associated behaviors for clients that is use= ful for authorization server implementations, even when the Dynamic Client = Registration Protocol isn't directly in play. This particular situation= seems like a good potential candidate for a new such client metadata param= eter that would indicate that the given client can only use a request_uri v= alue obtained from the PAR endpoint to initiate an authorization request. A= nd that a regular old fashioned authorization request from the given client= would result in an error.
>>>>
>>>> Do the folks of this fine WG think something like this wou= ld be a worthwhile addition to the PAR draft?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE: This email may contain confidentia= l and privileged material for the sole use of the intended recipient(s). An= y review, use, distribution or disclosure by others is strictly prohibited.= ...=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= ...org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d privileged material for the sole use of the intended recipient(s). Any re= view, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sen= der immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you.
>>> _______________________________________________
>>> 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/listinfo/oauth

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you.
--0000000000007fe2c105a49318bc-- From nobody Fri May 1 02:51:45 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF33A0DBF for ; Fri, 1 May 2020 02:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HWEC8pTZuuo for ; Fri, 1 May 2020 02:51:34 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79F73A0DA5 for ; Fri, 1 May 2020 02:51:34 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id 10so2577459vkr.7 for ; Fri, 01 May 2020 02:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B0w6yoQObMyI4f+GeMw+DXT5m5SCvnQ4/wOuCX1+LRQ=; b=6BRdP2m5TiisnoiEUONMO0TT117jvLx6+kv3/tg+1104zXR0ZjPNXjRzNukJlN1fuV +DQRzme9hkUDQsluBA+ViJITL844PJmIm3ZAswnRjqj0mAdnURlagsvePilzWf0RM+88 wIOQCtrIXLGFSmQznRQwrO+Wll1M5qQa1JtAeKio3+268954VDsy1NLMSa1L4rQaGS3u xiqy3uQWlHoeZxy6BHjgkHe3fY1yOHkgJDmmJi/+7x/tyRLTYurII3FY0nWdUanbMagA 8/OWJ362QuqD/PKsvIZ/JGkbj4FFw94PhWSIyKLNvTJUPE52VOpxFqvmsXXHqE24bdG5 +dFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B0w6yoQObMyI4f+GeMw+DXT5m5SCvnQ4/wOuCX1+LRQ=; b=nJYYog6nUmaJ380VC/whzScRVnwJCkw3zOJib7giKh2cWXvrR1xOiJsqcD9yE1c5IV q6NqRzi/KGbHTibiquvePenrgW0XsKnm6FRJrCRCdbI6XpajfyviyK/Wt6q6apIzZI03 CF32f71dZWS7JzN4wG/XYAfRJZkTpnjblFM2sGWVENFqLw+R7wVkN8tKoCIhekguHSqd UGkIAnH2/cDeHXpKnJSnPuaIOBPom2ATgQvLZ6bQl1tvfKTdRhJ1V9CK9mlHVN04T6wl 86lcuXAEkAwgNimyMpSaUfgv+IzN5jdopEd+kePqxM+fyvGec5uwpESh1b++BDMx6cd+ i9vQ== X-Gm-Message-State: AGi0PuYyzmjyPsZ6fM+QwJhITWJ7LtpUmzI5xGXNy43kuR6FVZnCqyKN fkM67O+XpFp/alK0FKUO7m+GGUOvQlNjCX9Uo7ce8w== X-Google-Smtp-Source: APiQypLYc6tfB5XTUiRuVqsDqK3YUkdG3s/3e/PtbbQPpH17cahWsVH1Y2k/1IvM96uhShlopCjYIsG6M+n7PGsrmQc= X-Received: by 2002:a1f:5cd5:: with SMTP id q204mr2041840vkb.21.1588326693749; Fri, 01 May 2020 02:51:33 -0700 (PDT) MIME-Version: 1.0 References: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net> In-Reply-To: From: Torsten Lodderstedt Date: Fri, 1 May 2020 11:51:22 +0200 Message-ID: To: Brian Campbell Cc: Filip Skokan , oauth Content-Type: multipart/alternative; boundary="0000000000005e60bc05a4932062" Archived-At: Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 09:51:44 -0000 --0000000000005e60bc05a4932062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Filip=C2=B4s proposal works for me. Are there any objections? Brian Campbell schrieb am M= o. 27. Apr. 2020 um 20:57: > While there are certainly different permutations and contexts of use that > could be imagine, I tend to agree with Filip here in not seeing a strong > need to define new PAR specific metadata around signing/encryption of the > request object. > > On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan wrote: > >> Considering there's going to be a setting that forces clients to use PAR >> (other mailinglist thread), then we should rely on the existing >> `request_object_signing_alg` presence to indicate a Request Object must = be >> used (as suggested by this upcoming OIDC Core errata >> ), >> regardless of it being PAR or JAR. I don't see the need for a PAR specif= ic >> metadata, for one - implementations wouldn't be easily able to re-use of >> existing pipelines, two - yes the contexts differ but do you think clien= ts >> will be using both channels at the same time? And even if so, the Reques= t >> Object is the same therefore its applicable to both channels the same. >> >> Best, >> *Filip Skokan* >> >> >> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt > 40lodderstedt.net@dmarc.ietf.org> wrote: >> >>> Hi all, >>> >>> this is one of the topics we quickly flipped through in the virtual >>> meeting last week. >>> >>> I see the following open questions: >>> - Can the client require its instances to use request objects only. >>> - Are there further requirements on the properties of these objects? >>> Signed only, Signed and encrypted, algorithms? >>> - Can an AS require ALL clients to use request objects only? >>> - Further requirements here as well? >>> - Is this tied to PAR or relevant for JAR as well? >>> >>> In my opinion, client as well as AS should be able to control enforced >>> use of request objects. >>> >>> I could imagine the setting for JAR request objects (=E2=80=9Crequest" >>> parameter) and request objects in the PAR context differ, as the first = case >>> goes through the user=E2=80=99s browser whereas the PAR case goes direc= t from >>> client to AS via a TLS protected channel. I therefore feel the settings >>> should be PAR specific. >>> >>> What do you think? >>> >>> best regards, >>> Torsten. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --0000000000005e60bc05a4932062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Filip=C2=B4s proposal works for me.

Are there any objections?

Bria= n Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> schrieb am Mo. 27. Apr. 2020= um 20:57:
While t= here are certainly different permutations and contexts of use that could be= imagine, I tend to agree with Filip here in not seeing a strong need to de= fine new PAR specific metadata around signing/encryption of the request obj= ect.

On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan <panva.ip@gmail.com> wrote:
<= div>Considering there's going to be a setting that forces clients to us= e PAR (other mailinglist thread), then we should rely on the existing `requ= est_object_signing_alg` presence to indicate a Request Object must be used = (as suggested by this upcoming OIDC Core errata), regardless of it being PAR or JAR. I don't see the= need for a PAR specific metadata, for one - implementations wouldn't b= e easily able to re-use of existing pipelines, two - yes the contexts diffe= r but do you think clients will be using both channels at the=C2=A0same tim= e? And even if so, the Request Object is the same therefore its applicable = to both channels the same.

Bes= t,
Filip Skokan


On Sun, 26 Apr 2020 at 17:09, Tors= ten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi all,

this is one of the topics we quickly flipped through in the virtual meeting= last week.

I see the following open questions:
- Can the client require its instances to use request objects only.
- Are there further requirements on the properties of these objects? Signed= only, Signed and encrypted, algorithms?
- Can an AS require ALL clients to use request objects only?
- Further requirements here as well?
- Is this tied to PAR or relevant for JAR as well?

In my opinion, client as well as AS should be able to control enforced use = of request objects.

I could imagine the setting for JAR request objects (=E2=80=9Crequest"= parameter) and request objects in the PAR context differ, as the first cas= e goes through the user=E2=80=99s browser whereas the PAR case goes direct = from client to AS via a TLS protected channel. I therefore feel the setting= s should be PAR specific.

What do you think?

best regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you.
--0000000000005e60bc05a4932062-- From nobody Fri May 1 05:28:47 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1FC3A115F for ; Fri, 1 May 2020 05:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7CwEFKrdtyQ for ; Fri, 1 May 2020 05:28:43 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8753A112F for ; Fri, 1 May 2020 05:28:43 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id e20so2385034otk.12 for ; Fri, 01 May 2020 05:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OcLOKictClL4jUJI5v9o3zoXc3a6ALKT0mczFkv8DFg=; b=HLAp4mXpPCvcA/ua10vlsO0G4BTkBLb6/9CI9l2Dlm8aHu7ssNeiQOMtPBJtizPYub rJs+0NYzRhtrGlO72OHkEi0BKv0bOCbfiVbdOhyaWC+lGFwxEFgb+bjbkc2wlYWJS48W wCFHSl2LPuqkFvrlJVhHRxrbaF45xmsBUYs/Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OcLOKictClL4jUJI5v9o3zoXc3a6ALKT0mczFkv8DFg=; b=HF/5YWdGrvC2JzkIoqYbz339RswLoITrSbuArbeq4TZXzZp7ryzMQKykZsdkmEZQN5 jHy1kyCe+lq8vOqPtvQ7KtJtJvTpW5T+h0qr8AoTh/N2W2aAwErMMhnWmqtMZyo1Uwbr 7DPUr9w6T+TZNQHwmqVkwZYLM5bZhB8giGc+0I/XWUJDLjyyAqo5uMPZnhRY8DK8uBz5 KHzI4b6xsHRmQFI+rUx6qzg4I1RWECwQTf+ua/UFAm22CoDTP80MRUhzpzaNtdburDcy SIBV3rhJQ+Sq+QPFMxIauOKWRvULt1VPnm2Wb+Ev2AbpQnUd4yaswL/CxgMCpA0uSa/m KIRQ== X-Gm-Message-State: AGi0PubClrRuMqRyXMsbQ3n+7a8ZwvpuR6eftga1f0KtUIWA2f/O60lT hmRsdm3wRhYe43V9xxf3AK8frWf+5gPm89YPyvRzKXH8eesahQ== X-Google-Smtp-Source: APiQypIsurjyv2HarYLR+yJeojjJfy2+C3lahcRfD6D/29f95fsp9rHn9xZ93bUpDiGuJ6MOkqJnDtvNfjqj9GoGv0w= X-Received: by 2002:a9d:4113:: with SMTP id o19mr3196927ote.354.1588336122476; Fri, 01 May 2020 05:28:42 -0700 (PDT) MIME-Version: 1.0 References: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net> In-Reply-To: From: Dave Tonge Date: Fri, 1 May 2020 14:28:31 +0200 Message-ID: To: Torsten Lodderstedt Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000005d579c05a4955209" Archived-At: Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 12:28:45 -0000 --0000000000005d579c05a4955209 Content-Type: text/plain; charset="UTF-8" Works for me also --0000000000005d579c05a4955209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Works for me also=C2=A0


--0000000000005d579c05a4955209-- From nobody Fri May 1 08:56:52 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEBC3A15E5 for ; Fri, 1 May 2020 08:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCDuXJwAYDm0 for ; Fri, 1 May 2020 08:56:42 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650115.outbound.protection.outlook.com [40.107.65.115]) (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 CEF483A154E for ; Fri, 1 May 2020 08:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K5drbMIgHvaW5WrccwyowaHyXBOKLz0WTP8Th+YDEw17s8SEB3nUkJuGbs/YOKl59AL7qeMCRFjYBBdUGRa9JgLZcYQ+X8v0JEpO+trDSmD+1+6GECXez+eUfQJgTftoX183IGI8DU0CdrBU52a4/CwzVrNXZ563y8wgXELBg/2xnM3SNACPGLmBoaK+qF1Q6hW9NiqZg5oBFafDdSm72hUxDR7EuKHg/wSzyEBdpruG8ll6Ap9nF8WU7ovWleWhUfdZDGznLzf75FVVI/KMhQkVRYnKdxv/U7Yw2P5DTiQIjd6ez/TLVFYZ/BwUhR8U2clxdopI/LRL73gRepXh+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ugtz0+8vDvLhtVKBpp7gltbIiYTKdBAMABd4dxoGLYk=; b=CB0mRC4vu1GMtR8AkXx+YY8pOVzFL6fiCLxyRXs5siRWOwfMIxEd7YvIbKY4jrfraUGwg9jusdHocFHdSygmYpmwdEqzDTin+Qq3YcvaPKUGuadgSxlGliZ8faamgNPcGtJ3xvTAUKQFUXEXVD2sL+VRlmprDC8VUCtsGOa3hOA3kEHryXWvFiSseP5KL6ad/ZyK5gtoVEQcOBawoqQ2AU9ckRhQwXPlmORkBfOuQxvIrYlKFCEDcBRZH/hMrdELyVhYtP/5r2YJFsV+yopKeF/tICnD0o751R3+WG316wa6RqfTIG/UW6CMJNJVUs/D0EdsAY4Iacqw7w915sHCfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ugtz0+8vDvLhtVKBpp7gltbIiYTKdBAMABd4dxoGLYk=; b=QlK98t2qI9vOGP+WSOL2/0ZKMaZriA6gokquxkIU17nF6fQgWxTAm9VroA/TaoBTFWjgLUGy+USAaieKk18g7EZS3JEnH8v7m/X8weyUccFnaho7WLBXUbSdFYxPIeWCgzxEUDf2au7tk3solfTm9G+tX49KsLSWCdbJ4qMOccE= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM5PR00MB0376.namprd00.prod.outlook.com (2603:10b6:4:a0::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2992.0; Fri, 1 May 2020 15:56:39 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::1834:c740:72aa:48dc]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::1834:c740:72aa:48dc%8]) with mapi id 15.20.3003.000; Fri, 1 May 2020 15:56:39 +0000 From: Mike Jones To: Torsten Lodderstedt , Brian Campbell CC: oauth Thread-Topic: [OAUTH-WG] PAR - Can AS/client require request object? Thread-Index: AdYf0RcM+SMXXXDgR7umPh9q+QpXmQ== Date: Fri, 1 May 2020 15:56:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=17b1b879-5aeb-4f2a-8bc1-000040be05b2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-01T15:56:11Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c455573f-be6e-48c3-1332-08d7ede83c0f x-ms-traffictypediagnostic: DM5PR00MB0376: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0390DB4BDA x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: avLUnNGLveuFDSeYlPUlunj6Pj6M0fXnj+e3mZ6CHGh3yG1VvfwNXeAev4SNakKeZm5y7scN3z8ZvgYDuOWXlVY/AAbSkGi5jbLFD+jv8zagfFaiyRqxDiT4o+dTaVo+0+RQNpLxwgJ50xcbpSffHrSyu78Wor+iIoQ4EffbqYFatjZbtAVuiAyK5AJrvtH6Uoev4L1AHrCrw50USkWn6aB8PiookHQFOoPgr3m3jHLpNGEyTYSmF16XX38n9JT1UZtqH+xCr9r1FpkhZF1ihH9fhpc7YSnOpSAdlcIwjvZMMxXZTtKSolFpO2Ho3X/BbCvAVXJMhI/AlDyIl+zp4c9CeBztuhfvYOUA3IVsxCfkI/LenM5WTFnC1qRWTLHnftO6NSz+KE6PUkmhdq7QOIZH59wB8tNngCmRk5+ifzoSViMyuEUeDW1aNsj6MB43R0L6G9vtpNezM6uypEX1OXOon7Gk8UA969vZRD/utsYbkVnVBMVpK+xxK/xkdQxX5Vb+kp45pWwvrKoRqfUmKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0682.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(346002)(396003)(376002)(366004)(76116006)(5660300002)(8990500004)(66556008)(66476007)(8936002)(8676002)(64756008)(66446008)(66946007)(2906002)(86362001)(7696005)(52536014)(33656002)(966005)(71200400001)(82950400001)(316002)(66574012)(10290500003)(4326008)(9686003)(186003)(82960400001)(26005)(55016002)(6506007)(478600001)(53546011)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ceCQf7/9gV5X+u+BCBqJ95e7+6nYiN7wAhQvq8UuEHB3L4vy3v9VOnosZ3mYgipmXqpt0g6oDYRdcI0fk97bLN/r2Vq8TZNZcUm3VWyJRgnhi/Rdr74/bSbzcLwKQ9hcfeOmrZwLUeHCAwuf1j7eBfvZDf8LsOxDi89n4b1dCTsauZ0/nNvroDEGL2bymmbj8oA29ONqriV50zq4V4l3oqQ9kMgUY/TxzGa8pJxu/bsJ5Zuo6PJ+IjQifHpYglyM0wpEHCZb6o7SqUVfaGH2cUtA/dn1cgvIQeIQixvSDKJ8xg9O6YfS6SKP9++sfqXDJeZkTCY6ZbSrXdAqZR/jbIcL/BRU8FPu+gLRP8GiU433H2OKZar7r87kscmOyUYttHhASIS+2xScKKqol+opUzcBiCNYqUsF7Y26eB1dIsCrjxkxhV75qms5k7UBMl6arlol4lWCn+58F1kzRXDX2rKVQVn7rg7d47AoDhLPW/x01FpXLtDZ9EZIOPERAtcnMCQX319EJFN/O+KYHOnzqggmZbDz0bVHlny3R455q66oo1bQn1iJncyMvcYI9DEyJ8K4G0aSH7jntjBRuM1XcSo24Pc4gmPKFAZyEBWpBTTnDnZFAOBFY2492v+sOKr+XxHNFHBQVVfbBzYIrnVK7Ifpxxmc2UR0UzVFI7a8j21D3V2+BJxvhFLXnEXrsK2z+a5cD691eTG/mBUpHF7jM6yvNaSS+r5ZXyn8To2F6VrzN73r2Q6imdQhljE4taU6Zn4QWsEUXltstc4AYo4ORajLoVit2H9KB2q/hqJ8fTo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0682FB5ABDAE909C7156564DF5AB0DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0682.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c455573f-be6e-48c3-1332-08d7ede83c0f X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2020 15:56:39.0537 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 79CXMtdojvi2wYWqDKpedxAM2nNIJ+fa8x17dVoAwennHkxofiNuaLyKy7S3J6HLTaHp8kG8M2UvcCF1R5+XgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0376 Archived-At: Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 15:56:45 -0000 --_000_DM6PR00MB0682FB5ABDAE909C7156564DF5AB0DM6PR00MB0682namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNlbnQ6IEZyaWRheSwgTWF5IDEsIDIwMjAg Mjo1MSBBTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29t QGRtYXJjLmlldGYub3JnPg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIFBBUiAtIENhbiBBUy9jbGllbnQgcmVxdWlyZSByZXF1ZXN0IG9iamVjdD8N Cg0KRmlsaXDCtHMgcHJvcG9zYWwgd29ya3MgZm9yIG1lLg0KDQpBcmUgdGhlcmUgYW55IG9iamVj dGlvbnM/DQoNCkJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+PiBz Y2hyaWViIGFtIE1vLiAyNy4gQXByLiAyMDIwIHVtIDIwOjU3Og0KV2hpbGUgdGhlcmUgYXJlIGNl cnRhaW5seSBkaWZmZXJlbnQgcGVybXV0YXRpb25zIGFuZCBjb250ZXh0cyBvZiB1c2UgdGhhdCBj b3VsZCBiZSBpbWFnaW5lLCBJIHRlbmQgdG8gYWdyZWUgd2l0aCBGaWxpcCBoZXJlIGluIG5vdCBz ZWVpbmcgYSBzdHJvbmcgbmVlZCB0byBkZWZpbmUgbmV3IFBBUiBzcGVjaWZpYyBtZXRhZGF0YSBh cm91bmQgc2lnbmluZy9lbmNyeXB0aW9uIG9mIHRoZSByZXF1ZXN0IG9iamVjdC4NCg0KT24gTW9u LCBBcHIgMjcsIDIwMjAgYXQgMjozNSBBTSBGaWxpcCBTa29rYW4gPHBhbnZhLmlwQGdtYWlsLmNv bTxtYWlsdG86cGFudmEuaXBAZ21haWwuY29tPj4gd3JvdGU6DQpDb25zaWRlcmluZyB0aGVyZSdz IGdvaW5nIHRvIGJlIGEgc2V0dGluZyB0aGF0IGZvcmNlcyBjbGllbnRzIHRvIHVzZSBQQVIgKG90 aGVyIG1haWxpbmdsaXN0IHRocmVhZCksIHRoZW4gd2Ugc2hvdWxkIHJlbHkgb24gdGhlIGV4aXN0 aW5nIGByZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZ2AgcHJlc2VuY2UgdG8gaW5kaWNhdGUgYSBS ZXF1ZXN0IE9iamVjdCBtdXN0IGJlIHVzZWQgKGFzIHN1Z2dlc3RlZCBieSB0aGlzIHVwY29taW5n IE9JREMgQ29yZSBlcnJhdGE8aHR0cHM6Ly9iaXRidWNrZXQub3JnL29wZW5pZC9jb25uZWN0L2lz c3Vlcy8xMDQ1L3NpZ25hbGxpbmctdGhhdC1hLXJlcXVlc3Qtb2JqZWN0LW11c3Q+KSwgcmVnYXJk bGVzcyBvZiBpdCBiZWluZyBQQVIgb3IgSkFSLiBJIGRvbid0IHNlZSB0aGUgbmVlZCBmb3IgYSBQ QVIgc3BlY2lmaWMgbWV0YWRhdGEsIGZvciBvbmUgLSBpbXBsZW1lbnRhdGlvbnMgd291bGRuJ3Qg YmUgZWFzaWx5IGFibGUgdG8gcmUtdXNlIG9mIGV4aXN0aW5nIHBpcGVsaW5lcywgdHdvIC0geWVz IHRoZSBjb250ZXh0cyBkaWZmZXIgYnV0IGRvIHlvdSB0aGluayBjbGllbnRzIHdpbGwgYmUgdXNp bmcgYm90aCBjaGFubmVscyBhdCB0aGUgc2FtZSB0aW1lPyBBbmQgZXZlbiBpZiBzbywgdGhlIFJl cXVlc3QgT2JqZWN0IGlzIHRoZSBzYW1lIHRoZXJlZm9yZSBpdHMgYXBwbGljYWJsZSB0byBib3Ro IGNoYW5uZWxzIHRoZSBzYW1lLg0KDQpCZXN0LA0KRmlsaXAgU2tva2FuDQoNCg0KT24gU3VuLCAy NiBBcHIgMjAyMCBhdCAxNzowOSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00MGxvZGRl cnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMu aWV0Zi5vcmc+PiB3cm90ZToNCkhpIGFsbCwNCg0KdGhpcyBpcyBvbmUgb2YgdGhlIHRvcGljcyB3 ZSBxdWlja2x5IGZsaXBwZWQgdGhyb3VnaCBpbiB0aGUgdmlydHVhbCBtZWV0aW5nIGxhc3Qgd2Vl ay4NCg0KSSBzZWUgdGhlIGZvbGxvd2luZyBvcGVuIHF1ZXN0aW9uczoNCi0gQ2FuIHRoZSBjbGll bnQgcmVxdWlyZSBpdHMgaW5zdGFuY2VzIHRvIHVzZSByZXF1ZXN0IG9iamVjdHMgb25seS4NCi0g QXJlIHRoZXJlIGZ1cnRoZXIgcmVxdWlyZW1lbnRzIG9uIHRoZSBwcm9wZXJ0aWVzIG9mIHRoZXNl IG9iamVjdHM/IFNpZ25lZCBvbmx5LCBTaWduZWQgYW5kIGVuY3J5cHRlZCwgYWxnb3JpdGhtcz8N Ci0gQ2FuIGFuIEFTIHJlcXVpcmUgQUxMIGNsaWVudHMgdG8gdXNlIHJlcXVlc3Qgb2JqZWN0cyBv bmx5Pw0KLSBGdXJ0aGVyIHJlcXVpcmVtZW50cyBoZXJlIGFzIHdlbGw/DQotIElzIHRoaXMgdGll ZCB0byBQQVIgb3IgcmVsZXZhbnQgZm9yIEpBUiBhcyB3ZWxsPw0KDQpJbiBteSBvcGluaW9uLCBj bGllbnQgYXMgd2VsbCBhcyBBUyBzaG91bGQgYmUgYWJsZSB0byBjb250cm9sIGVuZm9yY2VkIHVz ZSBvZiByZXF1ZXN0IG9iamVjdHMuDQoNCkkgY291bGQgaW1hZ2luZSB0aGUgc2V0dGluZyBmb3Ig SkFSIHJlcXVlc3Qgb2JqZWN0cyAo4oCccmVxdWVzdCIgcGFyYW1ldGVyKSBhbmQgcmVxdWVzdCBv YmplY3RzIGluIHRoZSBQQVIgY29udGV4dCBkaWZmZXIsIGFzIHRoZSBmaXJzdCBjYXNlIGdvZXMg dGhyb3VnaCB0aGUgdXNlcuKAmXMgYnJvd3NlciB3aGVyZWFzIHRoZSBQQVIgY2FzZSBnb2VzIGRp cmVjdCBmcm9tIGNsaWVudCB0byBBUyB2aWEgYSBUTFMgcHJvdGVjdGVkIGNoYW5uZWwuIEkgdGhl cmVmb3JlIGZlZWwgdGhlIHNldHRpbmdzIHNob3VsZCBiZSBQQVIgc3BlY2lmaWMuDQoNCldoYXQg ZG8geW91IHRoaW5rPw0KDQpiZXN0IHJlZ2FyZHMsDQpUb3JzdGVuLg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9y IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLi4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFu ZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_DM6PR00MB0682FB5ABDAE909C7156564DF5AB0DM6PR00MB0682namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+V29ya3MgZm9yIG1l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGgg Jmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpUb3Jz dGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDEsIDIwMjAgMjo1 MSBBTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbD00MHBpbmdp ZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7 b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFBB UiAtIENhbiBBUy9jbGllbnQgcmVxdWlyZSByZXF1ZXN0IG9iamVjdD88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpbGlwwrRzIHByb3Bvc2FsIHdvcmtzIGZv ciBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BcmUgdGhlcmUgYW55IG9iamVjdGlvbnM/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1w YmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnIj40 MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyBzY2hyaWViIGFtIE1vLiAy Ny4gQXByLiAyMDIwIHVtIDIwOjU3OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRoZXJlIGFyZSBjZXJ0YWlubHkg ZGlmZmVyZW50IHBlcm11dGF0aW9ucyBhbmQgY29udGV4dHMgb2YgdXNlIHRoYXQgY291bGQgYmUg aW1hZ2luZSwgSSB0ZW5kIHRvIGFncmVlIHdpdGggRmlsaXAgaGVyZSBpbiBub3Qgc2VlaW5nIGEg c3Ryb25nIG5lZWQgdG8gZGVmaW5lIG5ldyBQQVIgc3BlY2lmaWMgbWV0YWRhdGEgYXJvdW5kIHNp Z25pbmcvZW5jcnlwdGlvbiBvZiB0aGUgcmVxdWVzdCBvYmplY3QuDQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDI3LCAyMDIwIGF0IDI6 MzUgQU0gRmlsaXAgU2tva2FuICZsdDs8YSBocmVmPSJtYWlsdG86cGFudmEuaXBAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+cGFudmEuaXBAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNvbnNpZGVyaW5nIHRoZXJlJ3MgZ29pbmcgdG8gYmUgYSBzZXR0aW5nIHRoYXQg Zm9yY2VzIGNsaWVudHMgdG8gdXNlIFBBUiAob3RoZXIgbWFpbGluZ2xpc3QgdGhyZWFkKSwgdGhl biB3ZSBzaG91bGQgcmVseSBvbiB0aGUgZXhpc3RpbmcgYHJlcXVlc3Rfb2JqZWN0X3NpZ25pbmdf YWxnYCBwcmVzZW5jZSB0byBpbmRpY2F0ZSBhIFJlcXVlc3QgT2JqZWN0IG11c3QgYmUgdXNlZCAo YXMgc3VnZ2VzdGVkIGJ5IHRoaXMNCiB1cGNvbWluZyBPSURDIENvcmUgPGEgaHJlZj0iaHR0cHM6 Ly9iaXRidWNrZXQub3JnL29wZW5pZC9jb25uZWN0L2lzc3Vlcy8xMDQ1L3NpZ25hbGxpbmctdGhh dC1hLXJlcXVlc3Qtb2JqZWN0LW11c3QiIHRhcmdldD0iX2JsYW5rIj4NCmVycmF0YTwvYT4pLCBy ZWdhcmRsZXNzIG9mIGl0IGJlaW5nIFBBUiBvciBKQVIuIEkgZG9uJ3Qgc2VlIHRoZSBuZWVkIGZv ciBhIFBBUiBzcGVjaWZpYyBtZXRhZGF0YSwgZm9yIG9uZSAtIGltcGxlbWVudGF0aW9ucyB3b3Vs ZG4ndCBiZSBlYXNpbHkgYWJsZSB0byByZS11c2Ugb2YgZXhpc3RpbmcgcGlwZWxpbmVzLCB0d28g LSB5ZXMgdGhlIGNvbnRleHRzIGRpZmZlciBidXQgZG8geW91IHRoaW5rIGNsaWVudHMgd2lsbCBi ZSB1c2luZyBib3RoIGNoYW5uZWxzDQogYXQgdGhlJm5ic3A7c2FtZSB0aW1lPyBBbmQgZXZlbiBp ZiBzbywgdGhlIFJlcXVlc3QgT2JqZWN0IGlzIHRoZSBzYW1lIHRoZXJlZm9yZSBpdHMgYXBwbGlj YWJsZSB0byBib3RoIGNoYW5uZWxzIHRoZSBzYW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8YnI+DQo8Yj5GaWxpcCBTa29r YW48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBTdW4sIDI2IEFwciAyMDIwIGF0IDE3OjA5LCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3Jz dGVuPTxhIGhyZWY9Im1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBhbGwsIDxicj4NCjxicj4NCnRoaXMgaXMgb25lIG9mIHRoZSB0b3BpY3Mgd2UgcXVp Y2tseSBmbGlwcGVkIHRocm91Z2ggaW4gdGhlIHZpcnR1YWwgbWVldGluZyBsYXN0IHdlZWsuDQo8 YnI+DQo8YnI+DQpJIHNlZSB0aGUgZm9sbG93aW5nIG9wZW4gcXVlc3Rpb25zOjxicj4NCi0gQ2Fu IHRoZSBjbGllbnQgcmVxdWlyZSBpdHMgaW5zdGFuY2VzIHRvIHVzZSByZXF1ZXN0IG9iamVjdHMg b25seS48YnI+DQotIEFyZSB0aGVyZSBmdXJ0aGVyIHJlcXVpcmVtZW50cyBvbiB0aGUgcHJvcGVy dGllcyBvZiB0aGVzZSBvYmplY3RzPyBTaWduZWQgb25seSwgU2lnbmVkIGFuZCBlbmNyeXB0ZWQs IGFsZ29yaXRobXM/DQo8YnI+DQotIENhbiBhbiBBUyByZXF1aXJlIEFMTCBjbGllbnRzIHRvIHVz ZSByZXF1ZXN0IG9iamVjdHMgb25seT8gPGJyPg0KLSBGdXJ0aGVyIHJlcXVpcmVtZW50cyBoZXJl IGFzIHdlbGw/IDxicj4NCi0gSXMgdGhpcyB0aWVkIHRvIFBBUiBvciByZWxldmFudCBmb3IgSkFS IGFzIHdlbGw/IDxicj4NCjxicj4NCkluIG15IG9waW5pb24sIGNsaWVudCBhcyB3ZWxsIGFzIEFT IHNob3VsZCBiZSBhYmxlIHRvIGNvbnRyb2wgZW5mb3JjZWQgdXNlIG9mIHJlcXVlc3Qgb2JqZWN0 cy4NCjxicj4NCjxicj4NCkkgY291bGQgaW1hZ2luZSB0aGUgc2V0dGluZyBmb3IgSkFSIHJlcXVl c3Qgb2JqZWN0cyAo4oCccmVxdWVzdCZxdW90OyBwYXJhbWV0ZXIpIGFuZCByZXF1ZXN0IG9iamVj dHMgaW4gdGhlIFBBUiBjb250ZXh0IGRpZmZlciwgYXMgdGhlIGZpcnN0IGNhc2UgZ29lcyB0aHJv dWdoIHRoZSB1c2Vy4oCZcyBicm93c2VyIHdoZXJlYXMgdGhlIFBBUiBjYXNlIGdvZXMgZGlyZWN0 IGZyb20gY2xpZW50IHRvIEFTIHZpYSBhIFRMUyBwcm90ZWN0ZWQgY2hhbm5lbC4gSSB0aGVyZWZv cmUNCiBmZWVsIHRoZSBzZXR0aW5ncyBzaG91bGQgYmUgUEFSIHNwZWNpZmljLiA8YnI+DQo8YnI+ DQpXaGF0IGRvIHlvdSB0aGluaz88YnI+DQo8YnI+DQpiZXN0IHJlZ2FyZHMsPGJyPg0KVG9yc3Rl bi4gPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBv ciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4uJm5ic3A7IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR00MB0682FB5ABDAE909C7156564DF5AB0DM6PR00MB0682namp_-- From nobody Fri May 1 09:16:19 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1833A16CA for ; Fri, 1 May 2020 09:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocxqbzVHatnj for ; Fri, 1 May 2020 09:16:11 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650116.outbound.protection.outlook.com [40.107.65.116]) (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 258983A16BD for ; Fri, 1 May 2020 09:16:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZ5/0gkC/PK56Z6Wkttul328X1y2wqXpJdAGlH2Z75pRDkAtJcCEANIUsxsb/9QPjX2EbMm1AMdQcrtUZy/iUM1NNN6Og6Dqq6i0I5wV0NCpOpYTq0sBSHEKne1fbpc5UfRQ/GV5M2ciLtp8V+HLGGw2yD9+VnxhPAD8Ci42hqMnu7sRL7MmeHO0lX8GRmVHWvONlUv/JGddhja0ZhHu3WFpSEQMzxs3Le0Ti20i1w5LK/uozDoMcR6kI7ZgWnxZetx6VlwrY9kc3NUADlzEay5Z2VorhPup55x4yRTfoPpskM7IGf5REFW6HLEwvPR3e6QG3BbATbLDUxS81dp/1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJIsEc48J4aX8bNvQ2zQlcN/vWyzFhQlgYzpJ7XmL/A=; b=dDAd/0ix+9LK2iPNNn8Txvzs7kmtCxcHiZsDqC0Ywf1bNBm11gIqtRN/dNACiGsBxt09DXJKDI17bTXTVBtRb1dG/87L5QAekTyFJejTv2kg1WWlP3MXeuK2FnAk2938k7IZy+grUDPDeB239fO4v4CJXryRNg0onjsNgRftudZge9LSMqPc86gocVZM2i4mBJCsrhH4JDwloXmYRWeir39xpDc428POYLN0+YbnGB4grzBKocB2ZWYEvmvl2gWYla6cEcjXoZLmbndpOOAcTCT+EgOW7CokOzdwURB8SMojWt4K0JYE2DQUnF2EzKb11vtAtHiie2N7fWGBzTfzQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJIsEc48J4aX8bNvQ2zQlcN/vWyzFhQlgYzpJ7XmL/A=; b=QA+ge9u1l2dtLlF0l99/C+UrmrUKxS2/qxI1CAH4EeSbvYwC1UQrYa2jqlQmHLe9qbzsKhQvi8hmF7ccaNcw0SrKS03JkdQkgjFUcNF8GRl/nPdqPmkm+7U0QVP+IKGhSohZm8xW9hoRzE8FvpZYLs2j4zhJNIQZdKARXnBMVfs= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM5PR00MB0325.namprd00.prod.outlook.com (2603:10b6:4:9f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2992.0; Fri, 1 May 2020 16:16:09 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b%5]) with mapi id 15.20.3005.000; Fri, 1 May 2020 16:16:09 +0000 From: Mike Jones To: Torsten Lodderstedt , "bcampbell@pingidentity.com" CC: John Bradley , Nat Sakimura , oauth Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt Thread-Index: AdYf08/D15RWZZHgQ5qohqrDAE+Keg== Date: Fri, 1 May 2020 16:16:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a6d09887-623a-49d2-affe-00002f1560b3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-01T16:14:45Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3d799118-2022-4527-a77a-08d7edeaf561 x-ms-traffictypediagnostic: DM5PR00MB0325: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0390DB4BDA x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: afn1bPN79L248zb1eK9QtPfgyxSS6IJfZA9zqP/+y5voG/U8TqY86xQwAqRWpOMacYuPyUVu8fJnGmtHS/QGSVMXgMYU3VE6FuiyTwr6B+I9I7imVBtRM53/vXy8eiLtxh6T4OIBuNro4FRJ/moYxtuDUTp8h0oNO5mvo/z4fiCo6lVl33ZMCHzflkZjZoUScw6QOZ/K6L8K6vAIqS0GOF5bpFn0FUK6OdXEOqR2rMFBU+K0coKQy7RohOsWMLYWHoUqf1QG2Dg22mIuiEDQ3HuE8ECGsIVX8mSlkk+jLiwDhF5P/RPHWTKr6RCU9mn6ogww556alWd+V08XMUtF+2m2AUZhyq732D1wpIcnLv0wpp7bQkfP/DywVDZ/h6FL3IhlO/UIEpMjSTQO6y+nJKpYOMx5A1+kGFZvdTF3DUtxUorQtS67ywHdBp9c3836CaKhMU1VQuFsWGBTEdT0wewwzlBNzdUTJgppjbT3lJ6tNAiPdSbndeIHcdNPmWoD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(39860400002)(366004)(346002)(396003)(4326008)(86362001)(71200400001)(66476007)(9686003)(55016002)(186003)(52536014)(2906002)(21615005)(8676002)(64756008)(76116006)(66556008)(66446008)(8936002)(54906003)(6506007)(82960400001)(966005)(33656002)(478600001)(7696005)(26005)(66946007)(110136005)(8990500004)(53546011)(82950400001)(66574012)(5660300002)(316002)(10290500003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CCC7fdy6t3jzOifA6kNaAcD1OeQiL8hb9sN52ySFA/qLhUJ9ncAIIKFWcQ/585WVWHstfurowSlcCCqTDNCNXK8nBq9lA7RNdHXIt0KFIugO5nE2GlJfiVUZ2mkI0zCyvFVtymyItfo48sbNzEjWvalaUY1R4GX5V6VmylE0bsPGQ7m0l80PO/ISMGF22PBUYwnoQLf/j3nrzj7mH6ewJxuXEg564WcVj+iDMsA2SloYSKG43wJnQE4npTxZSwgv0yqKJtYcsZwHyhzk0XzQyHpWg//Mr8X+I9yQSsG6PPahHEQixWuhIrgRRfE17V83iHmaG+wfhqd4n7YySZRv63GRXzhFgKmVo7NXgdH5nQaDW0iQEHxBCtNLYMxi0dkksxVfIPUc+mSea80dNbu+vNcbtBomy0r5pJkEQfOF7jU8kutzXXWZoTXfQWP81gwbzQBOHJRNakyAVv+hhTap4mEdIQt0QSPZcOg6A3hgiV1P3Rn38xflJCQ/LEXf5mP6yKQyR4utzniKkJVKrL8AWr2u4EJjun1YoGvGbVnfE6mNbiHO4o+I1ZnHnEZzZenaZCeksrt4+vzqXH51RaJWtxlBvACJ6O7I/MtRferkL6cUJR/53XEU1eWU40bdo+cx2xx5gxyc6eDItfL/Q/JE3jGJBzzogN6jmqcV3XVaHHRo3l6fAnim3Q8qhb9tXf5rhZiOG9n4AynseGD/60vwB4EF4kfCPW7H7JuOcXzt8f441TJFJKiYrMDeFsHxnrWUMK8aDOjp4Fa0c3V606IY/unlUZmKZtpIpNY5fnJ7WVE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB068419E97B418CB70196A99BF5AB0DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d799118-2022-4527-a77a-08d7edeaf561 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2020 16:16:09.0216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AfJtZbEdaoROyJJtNIcm5UFpVx0E+xc0ExMcWF/cAMM/8WGgxK76hW3vm8RI9vW9iAzX7maOnvnxMlKF20cFqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0325 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 16:16:15 -0000 --_000_DM6PR00MB068419E97B418CB70196A99BF5AB0DM6PR00MB0684namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgTmF0IGhhc27igJl0IHlldCBwdWJsaXNoZWQgdGhlIEpBUiB1cGRhdGVz IHRoYXQgQnJpYW4gbWFkZS4gIERvIHdlIHdhbnQgdG8gYWRkIHRoaXMgdGV4dCB0byB0aGUgZWRp dG9y4oCZcyBkcmFmdCBiZWZvcmUgcHVibGlzaGluZz8NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogVG9yc3Rl biBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4N ClNlbnQ6IEZyaWRheSwgTWF5IDEsIDIwMjAgMjozNyBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBKb2huIEJyYWRsZXkgPGpicmFkbGV5QHl1Ymlj by5jb20+OyBOYXQgU2FraW11cmEgPG5hdEBzYWtpbXVyYS5vcmc+OyBvYXV0aCA8b2F1dGhAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9h dXRoLWp3c3JlcS0yMS50eHQNCg0KVGhhbmtzIE1pa2UuDQoNCkkgc3VnZ2VzdCB0byBhZGQgdGV4 dCB0byBKQVIgZGVzY3JpYmluZyB1c2Ugb2YgdGhpcyByZWdpc3RyeSB2YWx1ZXMgdG8gZGV0ZXJt aW5lIHRoZSByZXF1ZXN0IG9iamVjdCBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIGFsZ29yaXRobXMu DQoNCk1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PiBzY2hyaWViIGFtIE1p LiAyOS4gQXByLiAyMDIwIHVtIDAxOjM4Og0K4oCccmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGdf dmFsdWVzX3N1cHBvcnRlZOKAnSBhbmQgb3RoZXIgQVMgTWV0YWRhdGEgdmFsdWVzIGRlZmluZWQg YnkgT3BlbklEIENvbm5lY3QgRGlzY292ZXJ5IGFyZSBub3cgcmVnaXN0ZXJlZCBhdCBodHRwczov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRl cnMueGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGEuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IG5hdD1zYWtpbXVyYS5vcmdAbWcuc2FraW11cmEub3JnPG1haWx0bzpzYWtpbXVyYS5vcmdA bWcuLnNha2ltdXJhLm9yZz4gPG5hdD1zYWtpbXVyYS5vcmdAbWcuc2FraW11cmEub3JnPG1haWx0 bzpzYWtpbXVyYS5vcmdAbWcuc2FraW11cmEub3JnPj4gT24gQmVoYWxmIE9mIE5hdCBTYWtpbXVy YQ0KU2VudDogU3VuZGF5LCBBcHJpbCAyNiwgMjAyMCAxMDoyOSBBTQ0KVG86IFRvcnN0ZW4gTG9k ZGVyc3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRv OjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPj47IEpvaG4gQnJhZGxleSA8amJyYWRs ZXlAeXViaWNvLmNvbTxtYWlsdG86amJyYWRsZXlAeXViaWNvLmNvbT4+OyBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuLkpvbmVzQG1pY3Jvc29m dC5jb20+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLW9hdXRoLWp3c3JlcS0yMS50eHQNCg0KVGhhbmtzIE1pa2UuDQoNClJpZ2h0IGluIGFzIG11 Y2ggYXMgSSBuZXZlciBleHBlY3RlZCBKQVIgdG8gdGFrZSB0aGlzIGxvbmcsIEkgd2FzIGV4cGVj dGluZyB0aGUgZXJyYXRhIHRvIGJlIHB1Ymxpc2hlZCBhbmQgdGhlc2UgcGFyYW1zIHRvIGJlIHJl Z2lzdGVyZWQgbG9uZyBiZWZvcmUgYXMgd2VsbCA6LSkgQnV0IGl0IG1heSBiZSBhIGdvb2Qgc2ln biB0aGF0IHdlIElkZW50aXRlcmF0aSBhcmUgYWxsIHNvIGJ1c3kgdGhlc2UgZGF5cy4NCg0KTmF0 IFNha2ltdXJhDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHBzOi8vbmF0LnNha2lt dXJhLm9yZw0KMjAyMOW5tDTmnIgyN+aXpSAyOjE3ICswOTAw44CBTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ PiDjga7jg6Hjg7zjg6s6DQpUaGUgbmV4dCBlcnJhdGEgdmVyc2lvbiBvZiBPcGVuSUQgQ29ubmVj dCBEaXNjb3Zlcnkgd2lsbCByZWdpc3RlciB0aGUgcGFyYW1ldGVyIHJlcXVlc3Rfb2JqZWN0X3Np Z25pbmdfYWxnX3ZhbHVlc19zdXBwb3J0ZWQgYW5kIG90aGVyIHBhcmFtZXRlcnMgbm90IHByZXZp b3VzbHkgcmVnaXN0ZXJlZC4gU2VlIGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29u bmVjdC1kaXNjb3ZlcnktMV8wLTI5Lmh0bWwgZm9yIHRoZSBsYXRlc3QgcHVibGlzaGVkIGVycmF0 YSBkcmFmdC4NCg0KSSBjYW4gbWFrZSBhIHJlcXVlc3QgZm9yIGVhcmx5IHJlZ2lzdHJhdGlvbiBp ZiBpdCB3b3VsZCBiZSB1c2VmdWwuDQoNCi0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNlbnQ6 IFN1bmRheSwgQXByaWwgMjYsIDIwMjAgODoxNyBBTQ0KVG86IE5hdCBTYWtpbXVyYSA8bmF0QHNh a2ltdXJhLm9yZzxtYWlsdG86bmF0QHNha2ltdXJhLm9yZz4+OyBKb2huIEJyYWRsZXkgPGpicmFk bGV5QHl1Ymljby5jb208bWFpbHRvOmpicmFkbGV5QHl1Ymljby5jb20+Pg0KQ2M6IG9hdXRoIDxv YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjEudHh0DQoNCkhpIE5h dCAmIEpvaG4sDQoNCkkgdHJpZWQgdG8gZmluZCBvdXQgaG93IHNpZ25pbmcgJiBlbmNyeXB0aW9u IGFsZ29yaXRobXMgYXJlIGRldGVybWluZWQgaW4gdGhlIEpBUiBjb250ZXh0Lg0KDQpJIGp1c3Qg Zm91bmQgdGhpcyBub3RlIGluIHRoZSBoaXN0b3J5IGZvciAtMDc6ICJTdG9wcGVkIHRhbGtpbmcg YWJvdXQgcmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGfigJ0NCg0KSSBhc3N1bWUgeW91IGFzc3Vt ZSB0aGlzIGlzIGRvbmUgdmlhIGNsaWVudCByZWdpc3RyYXRpb24gcGFyYW1ldGVycyByZWdpc3Rl cmVkIGluIGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMv b2F1dGgtcGFyYW1ldGVycy54aHRtbCNjbGllbnQtbWV0YWRhdGE/IFdoeSBkb2VzbuKAmXQgSkFS IHN0YXRlIHNvPw0KDQpXaGF0IGlzIGFib3V0IGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IHRoZSBB Uz8gVGhlIHJlc3BlY3RpdmUgcGFyYW1ldGVycywgc3VjaCBhcyByZXF1ZXN0X29iamVjdF9zaWdu aW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkIGFyZSBub3QgcmVnaXN0ZXJlZCB5ZXQgaW4gaHR0cHM6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0 ZXJzLnhodG1sI2F1dGhvcml6YXRpb24tc2VydmVyLW1ldGFkYXRhLg0KDQpiZXN0IHJlZ2FyZHMs DQpUb3JzdGVuLg0KDQoNCk9uIDE5LiBBcHIgMjAyMCwgYXQgMjA6MzAsIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KDQpB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBX ZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXRyBvZiB0aGUgSUVURi4NCg0KVGl0bGUgOiBUaGUg T0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBKV1QgU2VjdXJlZCBBdXRob3JpemF0 aW9uIFJlcXVlc3QgKEpBUikNCkF1dGhvcnMgOiBOYXQgU2FraW11cmENCkpvaG4gQnJhZGxleQ0K RmlsZW5hbWUgOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMS50eHQNClBhZ2VzIDogMzENCkRh dGUgOiAyMDIwLTA0LTE5DQoNCkFic3RyYWN0Og0KVGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBp biBPQXV0aCAyLjAgZGVzY3JpYmVkIGluIFJGQyA2NzQ5IHV0aWxpemVzDQpxdWVyeSBwYXJhbWV0 ZXIgc2VyaWFsaXphdGlvbiwgd2hpY2ggbWVhbnMgdGhhdCBBdXRob3JpemF0aW9uIFJlcXVlc3QN CnBhcmFtZXRlcnMgYXJlIGVuY29kZWQgaW4gdGhlIFVSSSBvZiB0aGUgcmVxdWVzdCBhbmQgc2Vu dCB0aHJvdWdoDQp1c2VyIGFnZW50cyBzdWNoIGFzIHdlYiBicm93c2Vycy4gV2hpbGUgaXQgaXMg ZWFzeSB0byBpbXBsZW1lbnQsIGl0DQptZWFucyB0aGF0IChhKSB0aGUgY29tbXVuaWNhdGlvbiB0 aHJvdWdoIHRoZSB1c2VyIGFnZW50cyBhcmUgbm90DQppbnRlZ3JpdHkgcHJvdGVjdGVkIGFuZCB0 aHVzIHRoZSBwYXJhbWV0ZXJzIGNhbiBiZSB0YWludGVkLCBhbmQgKGIpDQp0aGUgc291cmNlIG9m IHRoZSBjb21tdW5pY2F0aW9uIGlzIG5vdCBhdXRoZW50aWNhdGVkLiBCZWNhdXNlIG9mDQp0aGVz ZSB3ZWFrbmVzc2VzLCBzZXZlcmFsIGF0dGFja3MgdG8gdGhlIHByb3RvY29sIGhhdmUgbm93IGJl ZW4gcHV0DQpmb3J3YXJkLg0KDQpUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIGFiaWxpdHkg dG8gc2VuZCByZXF1ZXN0IHBhcmFtZXRlcnMgaW4gYQ0KSlNPTiBXZWIgVG9rZW4gKEpXVCkgaW5z dGVhZCwgd2hpY2ggYWxsb3dzIHRoZSByZXF1ZXN0IHRvIGJlIHNpZ25lZA0Kd2l0aCBKU09OIFdl YiBTaWduYXR1cmUgKEpXUykgYW5kIGVuY3J5cHRlZCB3aXRoIEpTT04gV2ViIEVuY3J5cHRpb24N CihKV0UpIHNvIHRoYXQgdGhlIGludGVncml0eSwgc291cmNlIGF1dGhlbnRpY2F0aW9uIGFuZA0K Y29uZmlkZW50aWFsaXR5IHByb3BlcnR5IG9mIHRoZSBBdXRob3JpemF0aW9uIFJlcXVlc3QgaXMg YXR0YWluZWQuDQpUaGUgcmVxdWVzdCBjYW4gYmUgc2VudCBieSB2YWx1ZSBvciBieSByZWZlcmVu Y2UuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3 c3JlcS8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandz cmVxLTIxDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWp3 c3JlcS0yMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mDQpzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xz LmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLi5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0K --_000_DM6PR00MB068419E97B418CB70196A99BF5AB0DM6PR00MB0684namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj5JIGJlbGlldmUgdGhhdCBOYXQgaGFzbuKAmXQgeWV0IHB1Ymxpc2hlZCB0aGUgSkFS IHVwZGF0ZXMgdGhhdCBCcmlhbiBtYWRlLiZuYnNwOyBEbyB3ZSB3YW50IHRvIGFkZCB0aGlzIHRl eHQgdG8gdGhlIGVkaXRvcuKAmXMgZHJhZnQgYmVmb3JlIHB1Ymxpc2hpbmc/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5l dEBkbWFyYy5pZXRmLm9yZyZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSAxLCAy MDIwIDI6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gQnJhZGxleSAmbHQ7amJyYWRs ZXlAeXViaWNvLmNvbSZndDs7IE5hdCBTYWtpbXVyYSAmbHQ7bmF0QHNha2ltdXJhLm9yZyZndDs7 IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjEudHh0PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgTWlrZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdn ZXN0IHRvIGFkZCB0ZXh0IHRvIEpBUiBkZXNjcmliaW5nIHVzZSBvZiB0aGlzIHJlZ2lzdHJ5IHZh bHVlcyB0byBkZXRlcm1pbmUgdGhlIHJlcXVlc3Qgb2JqZWN0IHNpZ25pbmcgYW5kIGVuY3J5cHRp b24gYWxnb3JpdGhtcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9PGEg aHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBtaWNyb3NvZnQu Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgc2NocmllYiBhbSBNaS4gMjkuIEFwci4gMjAyMCB1 bSAwMTozODo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+4oCc cmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZOKAnSBhbmQgb3RoZXIg QVMgTWV0YWRhdGEgdmFsdWVzIGRlZmluZWQgYnkgT3BlbklEIENvbm5lY3QgRGlzY292ZXJ5IGFy ZSBub3cgcmVnaXN0ZXJlZCBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhodG1sI2F1dGhvcml6YXRp b24tc2VydmVyLW1ldGFkYXRhIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pYW5hLm9y Zy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjYXV0 aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGE8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IG5hdD08YSBocmVmPSJtYWlsdG86c2FraW11cmEu b3JnQG1nLi5zYWtpbXVyYS5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYS5vcmdAbWcuc2Fr aW11cmEub3JnPC9hPiAmbHQ7bmF0PTxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYS5vcmdAbWcuc2Fr aW11cmEub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmEub3JnQG1nLnNha2ltdXJhLm9yZzwv YT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5hdCBTYWtpbXVyYTxicj4NCjxiPlNlbnQ6PC9i PiBTdW5kYXksIEFwcmlsIDI2LCAyMDIwIDEwOjI5IEFNPGJyPg0KPGI+VG86PC9iPiBUb3JzdGVu IExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVuPTxhIGhyZWY9Im1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5l dEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbG9kZGVyc3RlZHQubmV0QGRtYXJj LmlldGYub3JnPC9hPiZndDs7IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpicmFk bGV5QHl1Ymljby5jb20iIHRhcmdldD0iX2JsYW5rIj5qYnJhZGxleUB5dWJpY28uY29tPC9hPiZn dDs7IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLi5Kb25lc0BtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1v YXV0aC1qd3NyZXEtMjEudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgbmFtZT0ibWVzc2Fn ZUJvZHlTZWN0aW9uIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBNaWtl LiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+UmlnaHQgaW4gYXMgbXVjaCBhcyBJIG5ldmVyIGV4cGVjdGVkIEpBUiB0byB0YWtlIHRoaXMg bG9uZywgSSB3YXMgZXhwZWN0aW5nIHRoZSBlcnJhdGEgdG8gYmUgcHVibGlzaGVkIGFuZCB0aGVz ZSBwYXJhbXMgdG8gYmUgcmVnaXN0ZXJlZCBsb25nIGJlZm9yZSBhcyB3ZWxsIDotKSBCdXQgaXQg bWF5IGJlIGENCiBnb29kIHNpZ24gdGhhdCB3ZSBJZGVudGl0ZXJhdGkgYXJlIGFsbCBzbyBidXN5 IHRoZXNlIGRheXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IG5hbWU9Im1lc3NhZ2VTaWduYXR1cmVTZWN0aW9uIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+TmF0IFNha2ltdXJhJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVm PSJodHRwczovL25hdC5zYWtpbXVyYS5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL25hdC5z YWtpbXVyYS5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+MjAyMDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj40PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjI3PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pelPC9zcGFuPiAyOjE3ICYjNDM7MDkwMDxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOAgTwvc3Bhbj5NaWtlDQog Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ow0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44Gu44Oh44O844OrPC9z cGFuPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+VGhlIG5leHQgZXJyYXRhIHZlcnNpb24gb2YgT3BlbklEIENvbm5lY3QgRGlz Y292ZXJ5IHdpbGwgcmVnaXN0ZXIgdGhlIHBhcmFtZXRlciByZXF1ZXN0X29iamVjdF9zaWduaW5n X2FsZ192YWx1ZXNfc3VwcG9ydGVkIGFuZCBvdGhlciBwYXJhbWV0ZXJzIG5vdCBwcmV2aW91c2x5 IHJlZ2lzdGVyZWQuIFNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5p ZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAtMjkuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAtMjkuaHRtbDwv YT4gZm9yIHRoZSBsYXRlc3QgcHVibGlzaGVkIGVycmF0YSBkcmFmdC48YnI+DQo8YnI+DQpJIGNh biBtYWtlIGEgcmVxdWVzdCBmb3IgZWFybHkgcmVnaXN0cmF0aW9uIGlmIGl0IHdvdWxkIGJlIHVz ZWZ1bC48YnI+DQo8YnI+DQotLSBNaWtlPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg T24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnI+DQpTZW50OiBTdW5kYXksIEFwcmls IDI2LCAyMDIwIDg6MTcgQU08YnI+DQpUbzogTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWls dG86bmF0QHNha2ltdXJhLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5hdEBzYWtpbXVyYS5vcmc8L2E+ Jmd0OzsgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86amJyYWRsZXlAeXViaWNvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmpicmFkbGV5QHl1Ymljby5jb208L2E+Jmd0Ozxicj4NCkNjOiBv YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxLnR4dDxicj4NCjxicj4NCkhpIE5hdCAm YW1wOyBKb2huLDxicj4NCjxicj4NCkkgdHJpZWQgdG8gZmluZCBvdXQgaG93IHNpZ25pbmcgJmFt cDsgZW5jcnlwdGlvbiBhbGdvcml0aG1zIGFyZSBkZXRlcm1pbmVkIGluIHRoZSBKQVIgY29udGV4 dC48YnI+DQo8YnI+DQpJIGp1c3QgZm91bmQgdGhpcyBub3RlIGluIHRoZSBoaXN0b3J5IGZvciAt MDc6ICZxdW90O1N0b3BwZWQgdGFsa2luZyBhYm91dCByZXF1ZXN0X29iamVjdF9zaWduaW5nX2Fs Z+KAnTxicj4NCjxicj4NCkkgYXNzdW1lIHlvdSBhc3N1bWUgdGhpcyBpcyBkb25lIHZpYSBjbGll bnQgcmVnaXN0cmF0aW9uIHBhcmFtZXRlcnMgcmVnaXN0ZXJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0 ZXJzLnhodG1sI2NsaWVudC1tZXRhZGF0YSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnho dG1sI2NsaWVudC1tZXRhZGF0YTwvYT4/IFdoeSBkb2VzbuKAmXQgSkFSIHN0YXRlIHNvPzxicj4N Cjxicj4NCldoYXQgaXMgYWJvdXQgYWxnb3JpdGhtcyBzdXBwb3J0ZWQgYnkgdGhlIEFTPyBUaGUg cmVzcGVjdGl2ZSBwYXJhbWV0ZXJzLCBzdWNoIGFzIHJlcXVlc3Rfb2JqZWN0X3NpZ25pbmdfYWxn X3ZhbHVlc19zdXBwb3J0ZWQgYXJlIG5vdCByZWdpc3RlcmVkIHlldCBpbg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJh bWV0ZXJzLnhodG1sI2F1dGhvcml6YXRpb24tc2VydmVyLW1ldGFkYXRhIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29h dXRoLXBhcmFtZXRlcnMueGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGE8L2E+Ljxi cj4NCjxicj4NCmJlc3QgcmVnYXJkcyw8YnI+DQpUb3JzdGVuLjxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNFNjdFMjIgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA4LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjMuNzVwdDttYXJnaW4tYm90 dG9tOjMuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDE5LiBBcHIgMjAyMCwgYXQg MjA6MzAsDQo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiB3cm90ZTo8YnI+DQo8YnI+DQo8 YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV0cgb2YgdGhlIElFVEYuPGJyPg0K PGJyPg0KVGl0bGUgOiBUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBKV1Qg U2VjdXJlZCBBdXRob3JpemF0aW9uIFJlcXVlc3QgKEpBUik8YnI+DQpBdXRob3JzIDogTmF0IFNh a2ltdXJhPGJyPg0KSm9obiBCcmFkbGV5PGJyPg0KRmlsZW5hbWUgOiBkcmFmdC1pZXRmLW9hdXRo LWp3c3JlcS0yMS50eHQ8YnI+DQpQYWdlcyA6IDMxPGJyPg0KRGF0ZSA6IDIwMjAtMDQtMTk8YnI+ DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQpUaGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGluIE9BdXRo IDIuMCBkZXNjcmliZWQgaW4gUkZDIDY3NDkgdXRpbGl6ZXM8YnI+DQpxdWVyeSBwYXJhbWV0ZXIg c2VyaWFsaXphdGlvbiwgd2hpY2ggbWVhbnMgdGhhdCBBdXRob3JpemF0aW9uIFJlcXVlc3Q8YnI+ DQpwYXJhbWV0ZXJzIGFyZSBlbmNvZGVkIGluIHRoZSBVUkkgb2YgdGhlIHJlcXVlc3QgYW5kIHNl bnQgdGhyb3VnaDxicj4NCnVzZXIgYWdlbnRzIHN1Y2ggYXMgd2ViIGJyb3dzZXJzLiBXaGlsZSBp dCBpcyBlYXN5IHRvIGltcGxlbWVudCwgaXQ8YnI+DQptZWFucyB0aGF0IChhKSB0aGUgY29tbXVu aWNhdGlvbiB0aHJvdWdoIHRoZSB1c2VyIGFnZW50cyBhcmUgbm90PGJyPg0KaW50ZWdyaXR5IHBy b3RlY3RlZCBhbmQgdGh1cyB0aGUgcGFyYW1ldGVycyBjYW4gYmUgdGFpbnRlZCwgYW5kIChiKTxi cj4NCnRoZSBzb3VyY2Ugb2YgdGhlIGNvbW11bmljYXRpb24gaXMgbm90IGF1dGhlbnRpY2F0ZWQu IEJlY2F1c2Ugb2Y8YnI+DQp0aGVzZSB3ZWFrbmVzc2VzLCBzZXZlcmFsIGF0dGFja3MgdG8gdGhl IHByb3RvY29sIGhhdmUgbm93IGJlZW4gcHV0PGJyPg0KZm9yd2FyZC48YnI+DQo8YnI+DQpUaGlz IGRvY3VtZW50IGludHJvZHVjZXMgdGhlIGFiaWxpdHkgdG8gc2VuZCByZXF1ZXN0IHBhcmFtZXRl cnMgaW4gYTxicj4NCkpTT04gV2ViIFRva2VuIChKV1QpIGluc3RlYWQsIHdoaWNoIGFsbG93cyB0 aGUgcmVxdWVzdCB0byBiZSBzaWduZWQ8YnI+DQp3aXRoIEpTT04gV2ViIFNpZ25hdHVyZSAoSldT KSBhbmQgZW5jcnlwdGVkIHdpdGggSlNPTiBXZWIgRW5jcnlwdGlvbjxicj4NCihKV0UpIHNvIHRo YXQgdGhlIGludGVncml0eSwgc291cmNlIGF1dGhlbnRpY2F0aW9uIGFuZDxicj4NCmNvbmZpZGVu dGlhbGl0eSBwcm9wZXJ0eSBvZiB0aGUgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGlzIGF0dGFpbmVk Ljxicj4NClRoZSByZXF1ZXN0IGNhbiBiZSBzZW50IGJ5IHZhbHVlIG9yIGJ5IHJlZmVyZW5jZS48 YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS88L2E+PGJyPg0KPGJy Pg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3Jl cS0yMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLWp3c3JlcS0yMTwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLWp3c3JlcS0yMTwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb2F1dGgtandzcmVx LTIxPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mPGJyPg0Kc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+ Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC4uaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz LzwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR00MB068419E97B418CB70196A99BF5AB0DM6PR00MB0684namp_-- From nobody Fri May 1 10:56:56 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB10D3A18D8 for ; Fri, 1 May 2020 10:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwitVG-9cJCc for ; Fri, 1 May 2020 10:56:50 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8432A3A18D9 for ; Fri, 1 May 2020 10:56:50 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id l18so1627746wrn.6 for ; Fri, 01 May 2020 10:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jINgiFeCGvYMG+bk9sC4rHD/ZvlQOyOujyARFLn2Gho=; b=EKZoTIJ4+g9G8WjiL9o9vuDv0ppiToXAXUjWkpuxhTIeAwc4jVB2zSU6eS73bhp5eC XA/nlXN+ASLqCA0W/Rof+52IcHfQfSv+MsITMVhHFXJidgKp5MqkdQ/acjZsXRUMQon+ q4jhrO1qwRWsP1/bCX3TyCU5WrTkFxQ8L+M3AU+koD1rM0HMx/EsLBWJ1CH3Sox4Jvhe Bi1Mnu5kawp6UPvLNdlbm+g8YpfIENZ3SnvHjLko8qtXGcmPTpCiqWkmUVayP6xWKzTg do6zdxicLm08SaA29/uRdPKt+7wLu1Coh5SAQ9CraVILWrzM4SIklVmsJYlI82fQfnGX zN4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jINgiFeCGvYMG+bk9sC4rHD/ZvlQOyOujyARFLn2Gho=; b=TR0qoS026+WG+aWk+K/b37F29L/WWZo5KtYlHA2yJ0L5MSpXav3yhG7QZdXky7ydZb mCDAdIbvAxGUOTCWIQBvieADy28PtYgjmapkW+456YJlGTM6b1tZ1+BKryNv+QD/ur0l 9r4GCZ/LeYbeObrAElfCyua59Qi0UnMaMX3m6Nwgtex2NWqGnOJ/CeJ4pAT62tCM8S/9 wy19s5NQ02yEq4u/G5oU7GFQ9KFC4zgoqZw+JkUEDD3M7fqGoefnr3UDHxcJauK+VF59 CveGkX89+4hNBmYez8oyS04Zd+m4C0JozIlC+SB0sbu+CPhKxbV1vTj5uaViiy+Z8Hep URGw== X-Gm-Message-State: AGi0PuYLCFLaifrBvJAtVB4NBc6qIoNtgs8QagjQui8RTWQQkCuNvOAn Bi1W6LJICculgxv4/0wRsM9Ahg== X-Google-Smtp-Source: APiQypLlYuYNPnaDDowE1Ca2BJDhWYNqHNEjlyymxz21OlzBIKv23BMJzlX37b+aUXID1pb6WkCKdg== X-Received: by 2002:a5d:45cf:: with SMTP id b15mr5115504wrs.78.1588355808775; Fri, 01 May 2020 10:56:48 -0700 (PDT) Received: from p200300eb8f301f21f5f78f2c395685eb.dip0.t-ipconnect.de (p200300EB8F301F21F5F78F2C395685EB.dip0.t-ipconnect.de. [2003:eb:8f30:1f21:f5f7:8f2c:3956:85eb]) by smtp.gmail.com with ESMTPSA id 2sm832675wre.25.2020.05.01.10.56.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2020 10:56:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Torsten Lodderstedt In-Reply-To: Date: Fri, 1 May 2020 19:56:47 +0200 Cc: "bcampbell@pingidentity.com" , John Bradley , Nat Sakimura , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <856DF98C-748B-4DF8-A81D-B146CB9CB629@lodderstedt.net> References: To: Mike Jones X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 17:56:55 -0000 I created a pull request = https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/4=20 > On 1. May 2020, at 18:16, Mike Jones = wrote: >=20 > I believe that Nat hasn=E2=80=99t yet published the JAR updates that = Brian made. Do we want to add this text to the editor=E2=80=99s draft = before publishing? > =20 > -- Mike > =20 > From: Torsten Lodderstedt =20= > Sent: Friday, May 1, 2020 2:37 AM > To: Mike Jones > Cc: John Bradley ; Nat Sakimura = ; oauth > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt > =20 > Thanks Mike. > =20 > I suggest to add text to JAR describing use of this registry values to = determine the request object signing and encryption algorithms.=20 > =20 > Mike Jones schrieb am = Mi. 29. Apr. 2020 um 01:38: > =E2=80=9Crequest_object_signing_alg_values_supported=E2=80=9D and = other AS Metadata values defined by OpenID Connect Discovery are now = registered at = https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#a= uthorization-server-metadata. > =20 > -- Mike > =20 > From: nat=3Dsakimura.org@mg.sakimura.org = On Behalf Of Nat Sakimura > Sent: Sunday, April 26, 2020 10:29 AM > To: Torsten Lodderstedt ; = John Bradley ; Mike Jones = > Cc: oauth > Subject: [EXTERNAL] Re: [OAUTH-WG] I-D Action: = draft-ietf-oauth-jwsreq-21.txt > =20 > Thanks Mike.=20 > =20 > Right in as much as I never expected JAR to take this long, I was = expecting the errata to be published and these params to be registered = long before as well :-) But it may be a good sign that we Identiterati = are all so busy these days.=20 > =20 > Nat Sakimura=20 > Chairman, OpenID Foundation=20 > https://nat.sakimura.org > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5 2:17 +0900=E3=80=81Mike Jones = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > The next errata version of OpenID Connect Discovery will register the = parameter request_object_signing_alg_values_supported and other = parameters not previously registered. = Seehttps://openid.net/specs/openid-connect-discovery-1_0-29.html for the = latest published errata draft. >=20 > I can make a request for early registration if it would be useful. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth On Behalf Of Torsten Lodderstedt > Sent: Sunday, April 26, 2020 8:17 AM > To: Nat Sakimura ; John Bradley = > Cc: oauth > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt >=20 > Hi Nat & John, >=20 > I tried to find out how signing & encryption algorithms are determined = in the JAR context. >=20 > I just found this note in the history for -07: "Stopped talking about = request_object_signing_alg=E2=80=9D >=20 > I assume you assume this is done via client registration parameters = registered in = https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#c= lient-metadata? Why doesn=E2=80=99t JAR state so? >=20 > What is about algorithms supported by the AS? The respective = parameters, such as request_object_signing_alg_values_supported are not = registered yet = inhttps://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml= #authorization-server-metadata. >=20 > best regards, > Torsten. >=20 >=20 >=20 > On 19. Apr 2020, at 20:30, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : The OAuth 2.0 Authorization Framework: JWT Secured = Authorization Request (JAR) > Authors : Nat Sakimura > John Bradley > Filename : draft-ietf-oauth-jwsreq-21.txt > Pages : 31 > Date : 2020-04-19 >=20 > Abstract: > The authorization request in OAuth 2.0 described in RFC 6749 utilizes > query parameter serialization, which means that Authorization Request > parameters are encoded in the URI of the request and sent through > user agents such as web browsers. While it is easy to implement, it > means that (a) the communication through the user agents are not > integrity protected and thus the parameters can be tainted, and (b) > the source of the communication is not authenticated. Because of > these weaknesses, several attacks to the protocol have now been put > forward. >=20 > This document introduces the ability to send request parameters in a > JSON Web Token (JWT) instead, which allows the request to be signed > with JSON Web Signature (JWS) and encrypted with JSON Web Encryption > (JWE) so that the integrity, source authentication and > confidentiality property of the Authorization Request is attained. > The request can be sent by value or by reference. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-21 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp..ietf.org/internet-drafts/ >=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 From nobody Fri May 1 11:19:03 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8303A191D for ; Fri, 1 May 2020 11:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiEQpUqx2L0s for ; Fri, 1 May 2020 11:18:58 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE9E3A1916 for ; Fri, 1 May 2020 11:18:45 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id z22so4331478lfd.0 for ; Fri, 01 May 2020 11:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SqQkitlT7ocz+ox9lgijMDun0FFk2JS/sSEGT+Ekye0=; b=QerqkHxDgYGUMjX8RlGEdNpqM27kfnTFN9cVcmCP+XCg+c0dkh5G/6NnUhYNLzWRuw 6C6vBXKXeVpE9ooKppJ9aIDZ1FdO2E0G+wUvZQtjDcworrO1yC6IUY8L2E9osvvlqo3M vhJr6YuRRfJ2i4rcPD2WyCrwCMLYmSsI2XkDsSdPH5fuKt+Cr4F+8xuBeJVJbi8vFdms H2R6qCbqwVfeKLCgON4B1EcFMZaUjNXXSYWm0QhYhbjLFhnwyv6PkuBM7EK6125V1Tf5 166sVWvU+SXV+QCbrBCLobpw5vjc9H8Ccndn7Zq3wsUOAns47FXOIdzR2kacNN4Gyx5E Qr0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SqQkitlT7ocz+ox9lgijMDun0FFk2JS/sSEGT+Ekye0=; b=UkyY3XahYnZxRmGCHmMaNIBnA3+YFjnDlsz2UyQ9MTFLFjYLQkFfjaM0XuwVDO6fpd C1O4e0CvKJ8tX42XlxOTfE+vSfqrzDxaS+s2TjLR4buPPgxXvaDM67LKeJiURwNxt7Mp 72Xso13TvrF0ONif9RbaypjIMH4Hi3432SZ1t7jVdjm1k2Y0D3jH6sJvSVc9C44L6Ukn K3Yz7ZEG9YftEnSvFhNkoA/Sd2UHj42XzUI1627Yqoll68x7o50+zaT41xPO2ompK03L zo9m4Nj8jq8uxYGMO2AfR8FHkVGz2PynMn/qTjUOjUqjrHspegeIb5oE/W8cNGX1VDqg JULg== X-Gm-Message-State: AGi0PuZdQNWUqyXYZcdVLUDFyUbJb/SQQATODYHTxUM8JnzD6xMCiUtY 0bbdMs4lfwsxM4LGoHTWkf460pSLuMOUJVp6CPhhIMRlBopaP7ZcKJ0MW4zjk2foLTyXieH9kwy cj61bep5/XmknmA== X-Google-Smtp-Source: APiQypJvq4ZoLPcGEkxvSEn3sbqCJzQK8XFYYK5OhlE0E834ykH0WlXX4L+l74XxsisN8rjICVyydrHNrIB7X4nYMQc= X-Received: by 2002:a05:6512:74:: with SMTP id i20mr3303646lfo.104.1588357123539; Fri, 01 May 2020 11:18:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Fri, 1 May 2020 12:18:17 -0600 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" , Dmitri Zagidulin Content-Type: multipart/alternative; boundary="0000000000002022a705a49a367d" Archived-At: Subject: Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 18:19:01 -0000 --0000000000002022a705a49a367d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Mike for sharing this summary of what sounds like it was a valuable discussion. I'm sorry that I wasn't "at" IIW so wasn't able to participate in the session. I will endeavor to incorporate the open issues into the presentation on DPoP for the virtual interim on Monday https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth to hopefully facitate some futher disscion and progress. On Thu, Apr 30, 2020 at 8:29 PM Mike Jones wrote: > Daniel Fett and David Waite (DW) hosted a great session on OAuth 2.0 > Demonstration of Proof-of-Possession at the Application Layer (DPoP) > at the virtualized > IIW this week. Attendees also > included Vittorio Bertocci, Justin Richer, Dmitri Zagidulin, and Tim > Cappalli. > > > > After Daniel and DW finished doing their overview of DPoP, I used some of > the time to discuss feedback on DPoP from Microsoft Azure Active Director= y > (AAD) engineers. We discussed: > > - *How do we know if the resource server supports DPoP?* One > suggestion was to use a 401 WWW-Authenticate response from the RS. We > learned at IIW that some are already doing this. People opposed tryin= g to > do Resource Metadata for this purpose alone. However, they were suppo= rtive > of defining AS Metadata to declare support for DPoP and Registration > Metadata to declare support for DPoP. This might declare the supporte= d > token_type values. > - *How do we know what DPoP signing algorithms are supported?* This > could be done via AS Metadata and possibly Registration Metadata. Peo= ple > were also in favor of having a default algorithm =E2=80=93 probably ES= 256. > Knowing this is important to preventing downgrade attacks. > - *Can we have server nonces? * A server nonce is a value provided by > the server (RS or AS) to be signed as part of the PoP proof. People a= greed > that having a server nonce would add additional security. It turns ou= t > that Dmitri is already doing this, providing the nonce as a > WWW-Authenticate challenge value. > - *Difficulties with **jti at scale.* Trying to prevent replay with > jti is problematic for large-scale deployments. Doing duplicate > detection across replicas requires ACID consistency, which is too expe= nsive > to be cost-effective.. Instead, large-scale implementations often use > short timeouts to limit replay, rather performing reliable duplicate > detection. > - *Is the DPoP signature really needed when requesting a bound token?* > It seems like the worst that could happen would be to create a token b= ound > to a key you don=E2=80=99t control, which you couldn=E2=80=99t use. D= aniel expressed > concern about this enabling substitution attacks. > - *It seems like the spec requires the same **token_type for both > access tokens and refresh tokens.* Whereas it would be useful to be > able to have DPoP refresh tokens and Bearer access tokens as a transit= ion > step. Justin pointed out that the OAuth 2 protocol only has one > token_type value =E2=80=93 not separate ones for the refresh token and= access > token. People agreed that this deserves consideration. > - *Symmetric keys are significantly more efficient than asymmetric > keys.* In discussions between John Bradley, Brian Campbell, and Mike > Jones at IETF 106, John worked out how to deliver the symmetric key to= the > Token Endpoint without an extra round trip, however it would likely be= more > complicated to deliver it to the resource without an extra round trip.= At > past IETFs, both Amazon and Okta have also advocated for symmetric key > support. > - *What are the problems resulting from PoP key reuse?* The spec > assumes that a client will use the same PoP key for singing multiple t= oken > requests, both for access token and refresh token requests. Is this a > security issue? Daniel responded that key reuse is typically only a > problem when the same key is used for different algorithms or in diffe= rent > application contexts, when this reuse enables substitution attacks. I= t=E2=80=99s > also the case that clients can choose to use different PoP keys whenev= er > they choose to. > - *Could access tokens be signed?* Having the DPoP key hash in the > access token is equivalent if the access token is integrity protected.= But > people said that many deployments don=E2=80=99t use structured access = tokens in > which the key hash can be included. For instance, Ping Identity uses > access tokens that are just database indexes. Would access token sign= ing > be needed then? > - *Why aren=E2=80=99t query parameters signed?* Daniel said that > canonicalization of query parameters that use different URL escape syn= taxes > for representations of the same characters would likely result in inte= rop > problems. People said that while SOAP deployments might have many log= ical > endpoints differentiated only by query parameters, that=E2=80=99s no l= onger the > normal pattern for REST systems. > > > > Thanks for the great discussion! > > > > -- Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000002022a705a49a367d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mike for sharing this summary of what sounds l= ike it was a valuable discussion. I'm sorry that I wasn't "at&= quot; IIW so wasn't able to participate in the session.
=
I will endeavor to incorporate the open issues into the pres= entation on DPoP for the virtual interim on Monday https://datatr= acker.ietf.org/meeting/interim-2020-oauth-07/session/oauth to hopefully= facitate some futher disscion and progress.=C2=A0

On Thu, Apr 30= , 2020 at 8:29 PM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

Daniel Fett and David Waite (DW) hosted a great sess= ion on OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DP= oP) at the virtualized IIW= this week.=C2=A0 Attendees also included Vittorio Bertocci, Justin Richer,= Dmitri Zagidulin, and Tim Cappalli.

=C2=A0

After Daniel and DW finished doing their overview of= DPoP, I used some of the time to discuss feedback on DPoP from Microsoft A= zure Active Directory (AAD) engineers.=C2=A0 We discussed:

  • How do we know if the resource server supp= orts DPoP?=C2=A0 One suggestion was to use a 401 WWW-Authenticate= response from the RS.=C2=A0 We learned at IIW that some are already doing = this.=C2=A0 People opposed trying to do Resource Metadata for this purpose = alone.=C2=A0 However, they were supportive of defining AS Metadata to declare support for DPoP and Registration Metadata to declare support f= or DPoP.=C2=A0 This might declare the supported token_type value= s.
  • How do we know what D= PoP signing algorithms are supported?=C2=A0 This could be done via AS M= etadata and possibly Registration Metadata.=C2=A0 People were also in favor= of having a default algorithm =E2=80=93 probably ES256.=C2=A0 Knowing this is important to preventing downgrad= e attacks.
  • Can we have s= erver nonces? =C2=A0A server nonce is a value provided by the server (RS or AS) to be= signed as part of the PoP proof.=C2=A0 People agreed that having a server = nonce would add additional security.=C2=A0 It turns out that Dmitri is alre= ady doing this, providing the nonce as a WWW-Authenticate= challenge value.
  • Diffic= ulties with jti at sc= ale.=C2=A0 Trying to prevent replay with jti is problemat= ic for large-scale deployments.=C2=A0 Doing duplicate detection across repl= icas requires ACID consistency, which is too expensive to be cost-effective= ..=C2=A0 Instead, large-scale implementations often use short timeouts to limit replay, rather performing reliable duplicate detec= tion.
  • Is the DPoP signat= ure really needed when requesting a bound token?=C2=A0 It seems like th= e worst that could happen would be to create a token bound to a key you don= =E2=80=99t control, which you couldn=E2=80=99t use.=C2=A0 Daniel expressed concern about this enabli= ng substitution attacks.
  • It seems like the spec requires the same token_type for both access tokens and refresh tokens.=C2=A0 Whereas it would be = useful to be able to have DPoP refresh tokens and Bearer access tokens as a= transition step.=C2=A0 Justin pointed out that the OAuth 2 protocol only has one Symmetric keys are = significantly more efficient than asymmetric keys.=C2=A0 In discussions= between John Bradley, Brian Campbell, and Mike Jones at IETF 106, John wor= ked out how to deliver the symmetric key to the Token Endpoint without an extra round tri= p, however it would likely be more complicated to deliver it to the resourc= e without an extra round trip.=C2=A0 At past IETFs, both Amazon and Okta ha= ve also advocated for symmetric key support.
  • What are the problems resulting from PoP key re= use? =C2=A0The spec assumes that a client will use the same PoP key for= singing multiple token requests, both for access token and refresh token requests.=C2=A0 Is this a security issue?=C2=A0 Daniel respo= nded that key reuse is typically only a problem when the same key is used f= or different algorithms or in different application contexts, when this reu= se enables substitution attacks.=C2=A0 It=E2=80=99s also the case that clients can choose to use different PoP keys whenever they c= hoose to.
  • Could a= ccess tokens be signed?=C2=A0 Having the DPoP key hash in the access to= ken is equivalent if the access token is integrity protected.=C2=A0 But peo= ple said that many deployments don=E2=80=99t use structured access tokens in which the key hash can be in= cluded.=C2=A0 For instance, Ping Identity uses access tokens that are just = database indexes.=C2=A0 Would access token signing be needed then?
  • Why aren=E2=80=99t query = parameters signed?=C2=A0 Daniel said that canonicalization of query par= ameters that use different URL escape syntaxes for representations of the s= ame characters would likely result in interop problems.=C2=A0 People said that while SOAP= deployments might have many logical endpoints differentiated only by query= parameters, that=E2=80=99s no longer the normal pattern for REST systems.<= b>

=C2=A0

Thanks for the great discussion!

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000002022a705a49a367d-- From nobody Fri May 1 11:24:09 2020 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 B13463A1945; Fri, 1 May 2020 11:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158835742964.12112.4414270250716230897@ietfa.amsl.com> Date: Fri, 01 May 2020 11:23:49 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 18:23:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP) Authors : Daniel Fett Brian Campbell John Bradley Torsten Lodderstedt Michael Jones David Waite Filename : draft-ietf-oauth-dpop-01.txt Pages : 22 Date : 2020-05-01 Abstract: This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-dpop-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 1 12:03:54 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407043A19FF for ; Fri, 1 May 2020 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f01bfEHIBPJv for ; Fri, 1 May 2020 12:03:50 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A0C3A19FE for ; Fri, 1 May 2020 12:03:50 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id w20so3544182ljj.0 for ; Fri, 01 May 2020 12:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IEl/pCK3Ay68qtgQJvPjFHPP9NWFK7cZgXJ7xO1MTv0=; b=XdZMx/SOy/MuWbREQOgJ2Y0iyJXCZlpaplBMeiQIVudPKo1/CVvX6HYqONaK/0/Hk8 TA3URHv6UieM+1Hizdgkl+2yyUqBhy4J24/GRnxdOMlxTpAp60vN2hU7bERtpQZTNa26 4fb9T/57a/pgQCNuwNYXtEXGgfXtk/J1MM/+9XDGPUNBeJWYHOmLkWFGUQbjAs/68jvo uVZU0VQwTObWDUzDPjuUBpeQlxJc8L5tCHTzNuDmFv1u2T8AXNH1A1Haw5BWKAhSntRP 3ebwUiF9Syqhd4gHJewNABWLXhrN/92F12e3RAndLgRz4HonLyNSgBZhDIuKaqHvcJl2 JInA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IEl/pCK3Ay68qtgQJvPjFHPP9NWFK7cZgXJ7xO1MTv0=; b=TEheyaAVlzo5UkONcTzK0WNnofbrZCGl+SoMU/Ykx8xMMQf7pp0ecnoxFpNzSqfT2n othxYPTY6ECxpUZ2Gl0N4yMTj45CEpwUb+tQifz2EXK0EjuKdPGYlJrekg1ZpvrStrmB rlxhNtOjCx2HdP8XA+R3IxQ1KGWrDv1PxGAhjkulzai7cOVzW12vKnuAlzvfp0fBdtqG RfMhz10s5NVJLSrGyzeicADG0a+F506r3h3nhGS01kYqG9QCK5u6XF6k0TkdOy8gT1Y7 7rYCEx2O+DA9MhVuIoUKDDlTY/GxsvqErifZJqHX1+zrxfPiCj2PlOwd2sAC6W5skPdU SjtA== X-Gm-Message-State: AGi0PuYHT/bQEbXnmErv07L5Y+CmMzWHesKKf1gXe0bVNbSYVRqkNC/p vAGyxhO7V5KSFs9rmNRik8KCMNnGECy2UGPyLCjRdn8fvxbfF4WHsdyc57E9SgZuezsfVFAmNOR AbSqFIn+jo2+R6OQVyyw= X-Google-Smtp-Source: APiQypKCh9wRziE+GrMwWPd5OmdukNm0XYCJs5db5YBb2+an0B1+9L6VFovZT2AD9/0t1a6qkOYMbVE7zRVBcJaMFdE= X-Received: by 2002:a2e:9455:: with SMTP id o21mr3214704ljh.245.1588359827546; Fri, 01 May 2020 12:03:47 -0700 (PDT) MIME-Version: 1.0 References: <158835743733.12112.7484502726888997082@ietfa.amsl.com> In-Reply-To: <158835743733.12112.7484502726888997082@ietfa.amsl.com> From: Brian Campbell Date: Fri, 1 May 2020 13:03:21 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000004c040305a49ad7d0" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 19:03:53 -0000 --0000000000004c040305a49ad7d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've pushed out a -01 revision of DPoP hopefully allowing folks enough time to read it before the interim meeting on Monday (apologies that it wasn't sooner but the edits took longer than expected or hoped). For ease of reference the changes in this revision are summarized below. There are, of course, still outstanding issues and discussion points that I hope to make some progress on during the interim meeting on Monday. -01 * Editorial updates * Attempt to more formally define the DPoP Authorization header scheme * Define the 401/WWW-Authenticate challenge * Added "invalid_dpop_proof" error code for DPoP errors in token request * Fixed up and added to the IANA section * Added "dpop_signing_alg_values_supported" authorization server metadata * Moved the Acknowledgements into an Appendix and added a bunch of names (best effort) ---------- Forwarded message --------- From: Date: Fri, May 1, 2020 at 12:24 PM Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt To: Torsten Lodderstedt , David Waite < david@alkaline-solutions.com>, John Bradley , Brian Campbell , Daniel Fett , Michael Jones A new version of I-D, draft-ietf-oauth-dpop-01.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-ietf-oauth-dpop Revision: 01 Title: OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP) Document date: 2020-05-01 Group: oauth Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-0= 1 Abstract: This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. 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 --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000004c040305a49ad7d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've pushed out a -01 revision of DPoP hopefully = allowing folks enough time to read it before the interim meeting on Monday = (apologies that it wasn't sooner but the edits took longer than expecte= d or hoped). For ease of reference the changes in this revision are summari= zed below. There are, of course, still outstanding issues and discussion po= ints that I hope to make some progress on during the interim meeting on Mon= day.

=C2=A0=C2=A0 -01

=C2=A0 =C2=A0*= =C2=A0Editorial updates
=C2=A0 =C2=A0* =C2=A0Attempt to more formally d= efine the DPoP Authorization header
=C2=A0 =C2=A0 =C2=A0 scheme
=C2= =A0 =C2=A0* =C2=A0Define the 401/WWW-Authenticate challenge
=C2=A0 =C2= =A0* =C2=A0Added "invalid_dpop_proof" error code for DPoP errors = in token
=C2=A0 =C2=A0 =C2=A0 request
=C2=A0 =C2=A0* =C2=A0Fixed up a= nd added to the IANA section
=C2=A0 =C2=A0* =C2=A0Added "dpop_signi= ng_alg_values_supported" authorization server
=C2=A0 =C2=A0 =C2=A0 = metadata
=C2=A0 =C2=A0* =C2=A0Moved the Acknowledgements into an Appendi= x and added a bunch of
=C2=A0 =C2=A0 =C2=A0 names (best effort)

-----= ----- Forwarded message ---------
From: <internet-drafts@ietf= .org>
Date: Fri, May 1, 2020 at 12:24 PM
Subject: New V= ersion Notification for draft-ietf-oauth-dpop-01.txt
To: Torsten Lodders= tedt <torst= en@lodderstedt.net>, David Waite <david@alkaline-solutions.com>, Jo= hn Bradley <ve7jt= b@ve7jtb.com>, Brian Campbell <bcampbell@pingidentity.com>, Daniel Fe= tt <mail@danielf= ett.de>, Michael Jones <mbj@microsoft.com>



A new version of I-D, draft-ietf-oauth-dpop-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dpop
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Demonstration of Proof-o= f-Possession at the Application Layer (DPoP)
Document date:=C2=A0 2020-05-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-ietf-oauth-dpop-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01

Abstract:
=C2=A0 =C2=A0This document describes a mechanism for sender-constraining OA= uth 2.0
=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application = level.
=C2=A0 =C2=A0This mechanism allows for the detection of replay attacks with= access
=C2=A0 =C2=A0and refresh tokens.




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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000004c040305a49ad7d0-- From nobody Sat May 2 05:15:14 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD58E3A0FD7 for ; Sat, 2 May 2020 05:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vI6LwzkKd2gz for ; Sat, 2 May 2020 05:15:08 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDD03A0FED for ; Sat, 2 May 2020 05:15:07 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id l11so5836921lfc.5 for ; Sat, 02 May 2020 05:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zpREfhF5FI9rTUTIkU5IQUH9OfvKuZhh6P9xFlAwMlg=; b=Ul8+fGneHMLstUl/uINRt0Fo02hOhPA63h98n4wNSs3G++NIQ0OIcO+yp7xo4ykY7+ 6m7uvzUQEwQ4qqVH3ncfz+ew3+YY6l5QcJYp/hM4HCiKCu3On5kIXrY9U+jCoYDnZdms yzSvMBcR6fLtDzYdjVKlyewzeRB2n+1qoi8nkOeW3M4De8fTv0R4iAJ8mw3FhQV9pVXf ztog9VgXOVz/ZSF5T2TZVd8b7e3uKjq2t2NE0AhGunAEoN88NoNfqD+o/BKS+LsLRe1t E8gLO6ykDI9LRa+QaooZVjP4SfC4u5Qkekyts5+feagisd93VI7UzPUqGHI1KkIOti+k NtPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zpREfhF5FI9rTUTIkU5IQUH9OfvKuZhh6P9xFlAwMlg=; b=pcYIwp10X3u4RbAqDIu68nyFGIxqRLvHt9Ya28vGBhxGGafVw8NeWLGcuOf3gsj7Wh O6GkBDdjNRYxr1zHghtCep/Fu73RmdN8wrx0LNb611YUK7Mlnse/nrmJehRHBSwj3xkD ac/R5x/GGbE1I7iIhZpqokb870tOy2NyDcNmgFVDnhKlEJnuWYjiUjTSoXuiyk0nlBl/ QxxSxI8HM7pPK7qBkR2nLVckvkE7t8upzeo4IzMlPBPJnUoujf42ABVpKMLndP7wtLZg 7Z7lYuvD+1VORXjxxgm/yxugNhC0LeqFo19dgyri3GwoMLqJy76zKc1Z4WiDOwObwkta BFqw== X-Gm-Message-State: AGi0Pubk/oaDDbxPth040WFEqfnr0otR+e+f3eB/pBRjw7yu4Ad5SpuL jBJpJQI7ViOhQKTWLdt+EpzlnRiZssMqsh7TPr5RnzGkfyF+uQfhaGETAZdE75Ufl5AMrAwx7yA buLFJEK4O3ZW7HdS1BUI= X-Google-Smtp-Source: APiQypIselgdxxNlDYNj+Qbp2p43qTamP5uySGa1CCAXvxWwtQd3eKBa6dhfUJ3H0wPdcHaro+5JPc5whDW3pDT1AQo= X-Received: by 2002:a05:6512:48d:: with SMTP id v13mr5373421lfq.196.1588421706099; Sat, 02 May 2020 05:15:06 -0700 (PDT) MIME-Version: 1.0 References: <158835743733.12112.7484502726888997082@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Sat, 2 May 2020 06:14:39 -0600 Message-ID: To: Denis , oauth Content-Type: multipart/alternative; boundary="0000000000008bc3c205a4a93f70" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 12:15:12 -0000 --0000000000008bc3c205a4a93f70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There was a link to the meeting info in an email I sent to the list earlier in the day: https://mailarchive.ietf.org/arch/msg/oauth/hpfcCk9EHKkOmruBN5VZwoyW9WQ/ Also https://datatracker.ietf.org/meeting/upcoming is the =E2=80=9Cofficial= page=E2=80=9D of upcoming meetings (OAuth, or otherwise) that has webex and other info on all secluded upcoming meetings. On Sat, May 2, 2020 at 2:14 AM Denis wrote: > Hello Brian, > > I browsed through the received emails but I could not find the informatio= n > about how to join the Monday interim meeting. > > Would you be able to send it or to recall it to the list ? > > Thanks, > > Denis > > I've pushed out a -01 revision of DPoP hopefully allowing folks enough > time to read it before the interim meeting on Monday > (apologies that it wasn't sooner but the edits took longer than expected > or hoped). For ease of reference the changes in this revision > are summarized below. There are, of course, still outstanding issues and > discussion points that I hope to make some progress > on during the interim meeting on Monday. > > -01 > > * Editorial updates > * Attempt to more formally define the DPoP Authorization header > scheme > * Define the 401/WWW-Authenticate challenge > * Added "invalid_dpop_proof" error code for DPoP errors in token > request > * Fixed up and added to the IANA section > * Added "dpop_signing_alg_values_supported" authorization server > metadata > * Moved the Acknowledgements into an Appendix and added a bunch of > names (best effort) > > ---------- Forwarded message --------- > From: > > Date: Fri, May 1, 2020 at 12:24 PM > Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt > To: Torsten Lodderstedt , David Waite < > david@alkaline-solutions.com>, John Bradley , Brian > Campbell , Daniel Fett , > Michael Jones > > > > A new version of I-D, draft-ietf-oauth-dpop-01.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-ietf-oauth-dpop > Revision: 01 > Title: OAuth 2.0 Demonstration of Proof-of-Possession at the > Application Layer (DPoP) > Document date: 2020-05-01 > Group: oauth > Pages: 22 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop= -01 > > Abstract: > This document describes a mechanism for sender-constraining OAuth 2.0 > tokens via a proof-of-possession mechanism on the application level. > This mechanism allows for the detection of replay attacks with access > and refresh tokens. > > > > > 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 > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008bc3c205a4a93f70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There was a link to the meeting info in an email I se= nt to the list earlier in the day: https://mailarchive.ietf.org/a= rch/msg/oauth/hpfcCk9EHKkOmruBN5VZwoyW9WQ/

Als= o https://datatra= cker.ietf.org/meeting/upcoming is the =E2=80=9Cofficial page=E2=80=9D o= f upcoming meetings (OAuth, or otherwise) that has webex and other info on= all secluded upcoming meetings.


On Sat, May 2, 2020 = at 2:14 AM Denis <denis.ietf@free.= fr> wrote:
=20
I've pushed out a -01 revision of DPoP hopefully allowing folks enough time to read it before the interim meeting on Monday
(apologies that it wasn't sooner but the edits took longer than expected or hoped). For ease of reference the changes in this revision
are summarized below. There are, of course, still outstanding issues and discussion points that I hope to make some progress
on during the interim meeting on Monday.

=C2=A0=C2=A0 -01

=C2=A0 =C2=A0* =C2=A0Editorial updates
=C2=A0 =C2=A0* =C2=A0Attempt to more formally define the DPoP Aut= horization header
=C2=A0 =C2=A0 =C2=A0 scheme
=C2=A0 =C2=A0* =C2=A0Define the 401/WWW-Authenticate challenge =C2=A0 =C2=A0* =C2=A0Added "invalid_dpop_proof" error c= ode for DPoP errors in token
=C2=A0 =C2=A0 =C2=A0 request
=C2=A0 =C2=A0* =C2=A0Fixed up and added to the IANA section
=C2=A0 =C2=A0* =C2=A0Added "dpop_signing_alg_values_supporte= d" authorization server
=C2=A0 =C2=A0 =C2=A0 metadata
=C2=A0 =C2=A0* =C2=A0Moved the Acknowledgements into an Appendix = and added a bunch of
=C2=A0 =C2=A0 =C2=A0 names (best effort)

---------- Forwarded messag= e ---------
From: <internet-drafts@ietf..org>
Date: Fri, May 1, 2020 at 12:24 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
To: Torsten Lodderstedt <torsten@lodderstedt.net>, David Waite <david@alkaline-solutions.com>, John Bradley <ve7jtb@ve7jtb.com>, Brian Campbell <bcampbell@pingidentity.com>, Daniel Fett <mail@danielfett.de>, Michael Jones <mbj@microsoft.com>



A new version of I-D, draft-ietf-oauth-dpop-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dp= op
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Demonstration = of Proof-of-Possession at the Application Layer (DPoP)
Document date:=C2=A0 2020-05-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-oauth-= dpop-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-ietf-oauth-dpop-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-0= 1

Abstract:
=C2=A0 =C2=A0This document describes a mechanism for sender-const= raining OAuth 2.0
=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application level.
=C2=A0 =C2=A0This mechanism allows for the detection of replay at= tacks with access
=C2=A0 =C2=A0and refresh tokens.




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



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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008bc3c205a4a93f70-- From nobody Sun May 3 14:02:28 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688153A11EE for ; Sun, 3 May 2020 14:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWdzsDKomLQ5 for ; Sun, 3 May 2020 14:02:25 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EF03A11EB for ; Sun, 3 May 2020 14:02:25 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id z2so10290315iol.11 for ; Sun, 03 May 2020 14:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fxFHkbT9wtT0oha7ofqTHwYkGjGFiMOLiFMu9RL0RV8=; b=c9Na47mAa+KDWo2xbvTM9gTQ57DGMhLs+ot9uVMXMl9fs6GmsnM54wfcl0X8bI8qVI 4IlLtO/sQIrAFlYTz19BN3qlOqyi5g7WQr4k5KlduLSxs0kisnGqjQ6AJtIfDfEiQWaX t5h92gc5XAD2MZpGRJGRh41HyyzMXxRJ+Uiq8zgUE4zMihxai1JNVdvSEwGEQ0Ep49sC N+IMNhvmsL8zjKP09E3EekY8Ig+ullZfMm2LbhjRo6JpaUMaurr2caSGU/pJvRtTgOkO NRvSGEc8aBvb0FucOTFkAHBmN5OGSzqBmCHdD7YF0+OjSH+IW4rcmFHn4UeXcSpcwGQv mlTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fxFHkbT9wtT0oha7ofqTHwYkGjGFiMOLiFMu9RL0RV8=; b=ZIB0mNPNljaH7o6FTQMsJIMiYVI7W19Vlo/bj12YrifvMR8C8xTRqfJecK07+CDXqS MuMHYChTbY07i2XS1Zim1oA3pyYURt8p7ReDXMRprvRKioyBgjGm97fD2kWsaVggt/sx r8iGdli/Ff6QqCcGtZDoMk+0OTiMuLhXndeGprdQwXgJGK/jEIhi6zg6qNei/23QgFOB OM6WOkP4/GNxKlTYgh3Ron20hCryuTvRI/lk+7VLYuM4DZ2uJWc4IA4UA1L48cG+DDcW Ibyh8awyvJR2ZA2N3qlQEi2r2zpbQ2j2t7AH2cBAliLBg2mwCVHL17zEe0aynkgnJa6Z cfnA== X-Gm-Message-State: AGi0PuZnPxoul0rP/yiANMiWoEkIdz3YJC82sYEbuMB8ewKRS6wZoyFb djTB6g6hkz5647XOJI4osI6gsEZ8nD9L6+PsZ831ElUWVTM= X-Google-Smtp-Source: APiQypJ0SCe03zIHrrqmbLXHTx3NOqnaet9+sY9+lQv1NLU5VvNo1FSJPKcOvksYCmtRb1ReIlnB3iwgXZkSDRmKxKY= X-Received: by 2002:a02:5249:: with SMTP id d70mr3344055jab.121.1588539744610; Sun, 03 May 2020 14:02:24 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sun, 3 May 2020 17:02:13 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000306ef105a4c4bb00" Archived-At: Subject: [OAUTH-WG] May 4th Interim Meeting Material X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 21:02:27 -0000 --000000000000306ef105a4c4bb00 Content-Type: text/plain; charset="UTF-8" All, Here is a link to the meeting material for tomorrow's meeting: https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth Regards, Rifaat & Hannes --000000000000306ef105a4c4bb00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Here is a link to the m= eeting material for tomorrow's meeting:
https://datatrac= ker.ietf.org/meeting/interim-2020-oauth-07/session/oauth=C2=A0=C2=A0

Regards,
=C2=A0Rifaat & Hannes
--000000000000306ef105a4c4bb00-- From nobody Sun May 3 15:45:25 2020 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 2AFA33A0877; Sun, 3 May 2020 15:45:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158854592412.14672.482214031802876197@ietfa.amsl.com> Date: Sun, 03 May 2020 15:45:24 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 22:45:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Incremental Authorization Author : William Denniss Filename : draft-ietf-oauth-incremental-authz-04.txt Pages : 11 Date : 2020-05-03 Abstract: OAuth 2.0 authorization requests that include every scope the client might ever need can result in over-scoped authorization and a sub- optimal end-user consent experience. This specification enhances the OAuth 2.0 authorization protocol by adding incremental authorization, the ability to request specific authorization scopes as needed, when they're needed, removing the requirement to request every possible scope that might be needed upfront. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-incremental-authz-04 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 Sun May 3 15:48:04 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC63A08E9 for ; Sun, 3 May 2020 15:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfEO0_dpUxeW for ; Sun, 3 May 2020 15:48:00 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6223A0877 for ; Sun, 3 May 2020 15:47:59 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id z17so7412232oto.4 for ; Sun, 03 May 2020 15:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JJQRZ/yprfaY/nxe86bPrZMMk8ZwZgfapAB7WbWOli4=; b=uB5sLyKSoAxguSSzqQCzgZULUQBStCV2rf7gzO6XxzaXH4m/MgGQh6T6kVjvPMBI+F i9+PCBh7yJyAnqoOiFMUbwhvN3BgLynE6oKis4rh4sy1OR9/ls32hMRYXmtVcyEH5AoA MoIlQEm8Qczu0qqsRIc26cXW8W8QIiKTuNm9EZ+FT7CkqMa+X+zBbRcsJCuMv5Q36Jt7 plm7RPh+QZ8Fl3a3eTr+tA71AU8nCD5EhKwuvGUWLJphCuyps6/A7Npa3mRU1KR+neQF xRu7ob1ms9PzIoL41Y9dME+P97+6QKlu+BKP0eY+iEFy5AJRDsobEo/yhRmjrvS+YfNA 4evQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JJQRZ/yprfaY/nxe86bPrZMMk8ZwZgfapAB7WbWOli4=; b=CXR6VfBm2feNFrGvOrLGJ00qcAteSOprIF+YyM/5ZQtRr8NknbByBKO2xWYvBPYuP8 DfAJPNKAAVs8E4kXNocLQbiYlQsl/uagt97ZvMZAJ2ChLEwbEAts046ZLJWTkZL2DMgF /y+w3AbxLp1z2OIsAuNlA3If3anq9GULXP5V0+GxzNvqWuHcr2jlXCLdkjDWvKBWab3j s/QEbEOTt8jreXEPEp1VR26Wqif8MB7sST+MM3TAcIT9uPa1MGYgrLDkuh95scm8H5Lq QziDweXHuJgUIoPcOFtcQaUdHgrm1ugqPZZcqhomiRYHcDjFGwXwXoOI/LPov1NNpl7p XIcQ== X-Gm-Message-State: AGi0PuZSFUj+GUgVThakrxbDEMpaNKJiulCKx84qKZLiNYU9wniQM8qh SQbR5A+bV/AQWvlYhAGUyiuljbWhvnbnYi6bD0wgga/x X-Google-Smtp-Source: APiQypIHKvZplzSdkwbuXCa6E7mvaSiGZrqhXP1VKRkYyXLZ04F3g6moSW/QX2/YiZbuI2ZlclwhnDH0AG8DklXBddM= X-Received: by 2002:a9d:4c88:: with SMTP id m8mr11352350otf.149.1588546078761; Sun, 03 May 2020 15:47:58 -0700 (PDT) MIME-Version: 1.0 References: <736340BF-B33D-4407-81AF-532C947F1243@xmlgrrl.com> In-Reply-To: From: William Denniss Date: Sun, 3 May 2020 15:47:46 -0700 Message-ID: To: Aaron Parecki Cc: oauth Content-Type: multipart/alternative; boundary="000000000000bc35ea05a4c6348f" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 22:48:03 -0000 --000000000000bc35ea05a4c6348f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Aaron, Thank you for your review. My replies are inline: On Thu, Nov 14, 2019 at 12:40 PM Aaron Parecki wrote: > My comments below: > > The term "client" and "app" appear in multiple places interchangeably. > Since "client" is the OAuth 2 term, the document should stick to that > and not use the more colloquial term, "app". > > * Section 4: "without the app needing to..." should be "without the > client needing to..." > * Section 7.1: "an app could maintain" should be "a client should maintai= n" > * Section 8.1: "an app may offer" should be "a client may offer", and > a few more times in that paragraph > > Thanks for the feedback, I've fixed this in 04. > Section 8.2 mentions a pretty broad recommendation "... what would > reasonably be needed by a single feature" but then stops short. I feel > like this could use some elaboration perhaps with examples, since it > feels a bit too vague as is. > Good idea, I've added an example. I also defined a dedicated error code for the authorization server to use when denying for this reason. > Section 9: Does including "public" in the > "incremental_authz_types_supported" value mean that the AS supports > the "existing_grant" parameter? It's not clear whether that is a 1:1 > correlation, since section 5 says that it is only "NOT RECOMMENDED" > for public clients to automatically approve requests rather than "MUST > NOT". > This could use some clarification on what it means exactly when > an AS advertises support for incremental authz. If this value does not > mean the "existing_grant" parameter is supported, do we instead need > some other way to indicate which type of incremental authz is > supported for public clients so that public clients know whether to > use existing_grant or include_granted_scopes? > Essentially, incremental_authz_types_supported =3D ["public"] means that "existing_grant" is supported, and ["confidential"], means that "include_granted_scopes" is supported. ["public", "confidential"] means they both are. On consideration, I think this was a bit confusing so I've reworded it. I'm going to consider it for another edit pass following tomorrow's meeting. Best, William ---- > Aaron Parecki > aaronparecki.com > > On Fri, Nov 8, 2019 at 4:19 PM Richard Backman, Annabelle > wrote: > > > > A few issues I noticed: > > > > > > > > There is no normative text describing AS behavior when > include_granted_scopes is =E2=80=9Cfalse=E2=80=9D or omitted. I suggest a= dding the > following to the parameter=E2=80=99s definition in section 4: > > > > When =E2=80=9Cfalse=E2=80=9D or omitted, the authorization server SHOUL= D NOT include > scopes that were not explicitly specified in the authorization request. > > > > Having written the above, I realize it conflicts with Section 3.3 of > 6749, which states =E2=80=9C[t]he authorization server MAY fully or parti= ally > ignore the scope requested by the client=E2=80=A6.=E2=80=9D I=E2=80=99m n= ot sure offhand how to > resolve that. > > > > > > > > Regarding section 6.1, I don=E2=80=99t think we can assume that an acce= ss_denied > just indicates a rejection of the incremental request. Depending on the > consent interface presented to the end user, it may make more sense for t= he > AS to interpret the denial as a retraction of the existing grant as well. > End users may expect that to be the case, particularly if the existing > scopes are listed in the consent display alongside the additional ones > being requested. I=E2=80=99m not sure we need normative changes, but some > non-normative guidance highlighting this would be helpful. > > > > [NIT] Extra =E2=80=9Cshould=E2=80=9D in the 4th sentence of 6.1. > > > > I disagree with the first sentence of section 8.2. If the process of > requesting consent is particularly expensive (e.g., if the client is an I= oT > device or otherwise has limited input/output and is using the device > authorization grant), then it may be appropriate for the client to > determine which features the end user wants to enable and make a single > authorization request for all of the necessary scopes. > > > > There is no guarantee that the resource owner in the incremental > authorization grant is the same as the resource owner in the original > authorization grant. For example, the end user may log into Account A > originally, but Account B for the incremental authorization, either > intentionally or by accident. As it stands, the client has no way of > knowing that this has happened. I don=E2=80=99t think there is a normativ= e fix for > this, but it should be called out as a new failure mode that gets > introduced when switching from bulk to incremental authorization. > > > > > > > > =E2=80=93 > > > > Annabelle Richard Backman > > > > AWS Identity > > > > > > > > > > > > From: OAuth on behalf of Brian Campbell > > > Date: Friday, November 8, 2019 at 2:36 PM > > To: William Denniss > > Cc: oauth > > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 > > > > > > > > You are welcome. I'm always happy to be able to help with a major > contribution such as this one :) > > > > > > > > I did read through the draft for WGLC back in September though and that > was the only issue that jumped out at me. > > > > > > > > > > > > On Wed, Nov 6, 2019 at 6:15 PM William Denniss 40google.com@dmarc.ietf.org> wrote: > > > > > > > > On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > > > Just noticed that something is missing in > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02#section= -5 > where it has just, "(Section 4.1.4 of )" > > > > > > > > Thank you for catching this Brian. It was meant to read Section 4.1.4 o= f > RFC 6749. > > > > > > > > I've updated this in my local copy, will get posted in version 04. > > > > > > > > > > > > On Thu, Sep 12, 2019 at 8:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > > > Thanks for the correction; yes =E2=80=93 the most recent version is -02= and I > posted an old link. > > > > > > > > > > > > From: Eve Maler > > Sent: Donnerstag, 12. September 2019 16:16 > > To: Hannes Tschofenig > > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 > > > > > > > > I think you mean > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02? > > > > Eve Maler (sent from my iPad) | cell +1 425 345 6756 <(425)%20345-6756> > > > > > > On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > > > Hi all, > > > > > > > > We are starting a WGLC on the "OAuth 2.0 Incremental Authorization" > draft. You can find the document here: > > > > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01 > > > > > > > > Please review the document and provide feedback. > > > > > > > > The WGLC will end September 25th, 2019. > > > > > > > > Ciao > > > > Hannes & Rifaat > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited... If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any fi= le > attachments from your computer. Thank > you._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --000000000000bc35ea05a4c6348f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aaron,

Thank you for your re= view.

My replies are inline:

On Thu, Nov 14, 2019= at 12:40 PM Aaron Parecki <aaron@parecki.com> wrote:
My comments below:

The term "client" and "app" appear in multiple places i= nterchangeably.
Since "client" is the OAuth 2 term, the document should stick to = that
and not use the more colloquial term, "app".

* Section 4: "without the app needing to..." should be "with= out the
client needing to..."
* Section 7.1: "an app could maintain" should be "a client s= hould maintain"
* Section 8.1: "an app may offer" should be "a client may of= fer", and
a few more times in that paragraph

Thanks for the feedback, I've fixed this in 04.
=C2=A0
Section 8.2 mentions a pretty broad recommendation "... what would
reasonably be needed by a single feature" but then stops short. I feel=
like this could use some elaboration perhaps with examples, since it
feels a bit too vague as is.
=C2=A0
Good ide= a, I've added an example. I also defined a dedicated error code for the= authorization server to use when denying for this reason.
=C2=A0=
Section 9: Does including "public" in the
"incremental_authz_types_supported" value mean that the AS suppor= ts
the "existing_grant" parameter? It's not clear whether that i= s a 1:1
correlation, since section 5 says that it is only "NOT RECOMMENDED&quo= t;
for public clients to automatically approve requests rather than "MUST=
NOT".
=C2=A0
This could use some clarification on what it means exac= tly when
an AS advertises support for incremental authz. If this value does not
mean the "existing_grant" parameter is supported, do we instead n= eed
some other way to indicate which type of incremental authz is
supported for public clients so that public clients know whether to
use existing_grant or include_granted_scopes?

Essentially, incremental_authz_types_supported =3D ["public&quo= t;] means that "existing_grant" is supported, and ["confiden= tial"], means that "include_granted_scopes" is supported. [&= quot;public", "confidential"] means they both are.

On consideration, I think this was a bit confusing so I'= ;ve reworded it. I'm going to consider it for another edit pass followi= ng tomorrow's meeting.

Best,
William=


----
Aaron Parecki
aa= ronparecki.com

On Fri, Nov 8, 2019 at 4:19 PM Richard Backman, Annabelle
<richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> A few issues I noticed:
>
>
>
> There is no normative text describing AS behavior when include_granted= _scopes is =E2=80=9Cfalse=E2=80=9D or omitted. I suggest adding the followi= ng to the parameter=E2=80=99s definition in section 4:
>
> When =E2=80=9Cfalse=E2=80=9D or omitted, the authorization server SHOU= LD NOT include scopes that were not explicitly specified in the authorizati= on request.
>
> Having written the above, I realize it conflicts with Section 3.3 of 6= 749, which states =E2=80=9C[t]he authorization server MAY fully or partiall= y ignore the scope requested by the client=E2=80=A6.=E2=80=9D I=E2=80=99m n= ot sure offhand how to resolve that.
>
>
>
> Regarding section 6.1, I don=E2=80=99t think we can assume that an acc= ess_denied just indicates a rejection of the incremental request. Depending= on the consent interface presented to the end user, it may make more sense= for the AS to interpret the denial as a retraction of the existing grant a= s well. End users may expect that to be the case, particularly if the exist= ing scopes are listed in the consent display alongside the additional ones = being requested. I=E2=80=99m not sure we need normative changes, but some n= on-normative guidance highlighting this would be helpful.
>
> [NIT] Extra =E2=80=9Cshould=E2=80=9D in the 4th sentence of 6.1.
>
> I disagree with the first sentence of section 8.2. If the process of r= equesting consent is particularly expensive (e.g., if the client is an IoT = device or otherwise has limited input/output and is using the device author= ization grant), then it may be appropriate for the client to determine whic= h features the end user wants to enable and make a single authorization req= uest for all of the necessary scopes.
>
> There is no guarantee that the resource owner in the incremental autho= rization grant is the same as the resource owner in the original authorizat= ion grant. For example, the end user may log into Account A originally, but= Account B for the incremental authorization, either intentionally or by ac= cident. As it stands, the client has no way of knowing that this has happen= ed. I don=E2=80=99t think there is a normative fix for this, but it should = be called out as a new failure mode that gets introduced when switching fro= m bulk to incremental authorization.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampb= ell=3D40pingidentity.com@dmarc.ietf.org>
> Date: Friday, November 8, 2019 at 2:36 PM
> To: William Denniss <wdenniss=3D40google.com@dmarc.ietf.org>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01<= br> >
>
>
> You are welcome. I'm always happy to be able to help with a major = contribution such as this one :)
>
>
>
> I did read through the draft for WGLC back in September though and tha= t was the only issue that jumped out at me.
>
>
>
>
>
> On Wed, Nov 6, 2019 at 6:15 PM William Denniss <wdenniss=3D40google.com@dmar= c.ietf.org> wrote:
>
>
>
> On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:
>
> Just noticed that something is missing in https://tools.ietf.org/html/draft-ietf-oauth-incremen= tal-authz-02#section-5 where it has just, "(Section 4.1.4 of )&quo= t;
>
>
>
> Thank you for catching this Brian. It was meant to read Section 4.1.4 = of RFC 6749.
>
>
>
> I've updated this in my local copy, will get posted in version 04.=
>
>
>
>
>
> On Thu, Sep 12, 2019 at 8:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>
> Thanks for the correction; yes =E2=80=93 the most recent version is -0= 2 and I posted an old link.
>
>
>
>
>
> From: Eve Maler <eve@xmlgrrl.com>
> Sent: Donnerstag, 12. September 2019 16:16
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01<= br> >
>
>
> I think you mean https://tools= .ietf.org/html/draft-ietf-oauth-incremental-authz-02?
>
> Eve Maler (sent from my iPad) | cell +1 425 345 6756
>
>
> On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com&g= t; wrote:
>
> Hi all,
>
>
>
> We are starting a WGLC on the "OAuth 2.0 Incremental Authorizatio= n" draft. You can find the document here:
>
> https://tools.ietf.org/html/dr= aft-ietf-oauth-incremental-authz-01
>
>
>
> Please review the document and provide feedback.
>
>
>
> The WGLC will end September 25th, 2019.
>
>
>
> Ciao
>
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited...=C2=A0 If = you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from you= r computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y= ou have received this communication in error, please notify the sender imme= diately by e-mail and delete the message and any file attachments from your= computer. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
--000000000000bc35ea05a4c6348f-- From nobody Sun May 3 15:53:28 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFDB3A090E for ; Sun, 3 May 2020 15:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sgSY7ic2Yhb for ; Sun, 3 May 2020 15:53:24 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BF13A090C for ; Sun, 3 May 2020 15:53:23 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id m18so7371500otq.9 for ; Sun, 03 May 2020 15:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pX94PtaGpM37LkGKycYebA8fQJ4bwaUpQFTYEikevM0=; b=Uzm7SmfLu/ihBnceMHcINyWSFP0QFcTdfxzJNR/k7yoqkHuc9f+Y9Zg2zjnOydL7lb /s/Okp50Ux8nSeXOfR/VxVTrxwVbgG6nGo8dKnJZ6/4pDEO8oRyknpq0JjOCnMU/t2xD sVuxFwWP/P3eumQY6rv1lqwK5gfU5pjtbLMA5lIbhDn/PdgtORAm1nEZ365J5s1pMEcT 2hlU2pUGcefKtIQFjWdN3xUjA6OAeFmgznEagoUrDzvsoxRKc5PMHFTmIf+v2xlYxbcR NoXWTj4eOuaDhlacXU6FAC2Y5+ETFqw91NHcOy/GEtqCCYkabEighf//l0UK2QJaXJUk yWog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pX94PtaGpM37LkGKycYebA8fQJ4bwaUpQFTYEikevM0=; b=B7EWEiulvRUpgBwFH9VbsDDmIj90+MSgXc7+h2BpoZejrExrS70oXbnCYgiH+iaA5u MusE+jWxWXpsXfBq1aPIJ/jo7OPPF0XmgKVUPh3kPUwywJ9d9E+5s5DKr8U7edqLfvvF AtkFDEgVM0vT6tynl3QohgUN11EtRt0qttaTKFQa3uzH9YvW57eH28RH8XZC7qn0h4Vb fq6LFDcCiPYrT8Po1+T4M5rLCsPUShy5PBDDZ5BTD4ALZYjX8DevKX1DiyPDeHmlj04X lRqVXjLdI8GYQj8zTWwLH7uGQYNIOxqvV+rx2weqePR/1x0a07dOi6Q3cZaXFAWDxXWR bRuA== X-Gm-Message-State: AGi0PuY2A6J8M/owsIrZ8p6dnsvLQzrsgs8S+zoqBmU8GFBpk92r7S00 isKnrMyeObHA+JdG1HqGmeqSihEvAV4/ZrJrHKU6vj+ZFY0= X-Google-Smtp-Source: APiQypITFf5D++BTX8eeoEHeVAbX7fuxVawJlaNBY7k11mO87OiX+rSqfzI19b0tUQ3HYwZ6dNkP0KwlUhMqVYQmvs0= X-Received: by 2002:a9d:7ada:: with SMTP id m26mr11577787otn.181.1588546402803; Sun, 03 May 2020 15:53:22 -0700 (PDT) MIME-Version: 1.0 References: <736340BF-B33D-4407-81AF-532C947F1243@xmlgrrl.com> In-Reply-To: From: William Denniss Date: Sun, 3 May 2020 15:53:10 -0700 Message-ID: To: Naveen Agarwal , oauth Content-Type: multipart/alternative; boundary="0000000000000cada705a4c64800" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 22:53:26 -0000 --0000000000000cada705a4c64800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Posting this to the list with Naveen's permission, see his comment below, and my response: On Thu, Nov 7, 2019 at 12:51 AM Naveen Agarwal wrote: > Hi William, > > One nit.. on page 5 I think "requires" should be "required" > > "If later the user interacts with > the calendar or contacts features then, and only then, should the > require*s* scopes be requested. " > > I've fixed this in my staged copy, will land in version 05. > Separately I think it may be worth adding somewhere (with more privacy c= onscious users and awareness) > > that if authorization server does not show currently granted scopes, then= a user may assume that the current set of scopes > > are all they are granting to this client. Leading to privacy issues. > > Thank you for your review Naveen, I appreciate your feedback. I added a section to address this topic, "Previously Granted Scopes" (in version 04). One challenge is that this advice can only apply to clients that can't be impersonated (like confidential clients), as otherwise the display could be inaccurate. > Also a server could revalidate existing scopes and a user could deny them= . A client should be able to handle that. > > It would be good to guide clients on this possibility, I agree. I added a new section "Handling Scope Reductions" (in version 04) to discuss some of these possibilities and how they should be handled. Regards, William > Thanks > > > Naveen > > > On Wed, Nov 6, 2019 at 5:15 PM William Denniss 40google.com@dmarc.ietf.org> wrote: > >> >> On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> Just noticed that something is missing in >>> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02#secti= on-5 >>> where it has just, "(Section 4.1.4 of )" >>> >> >> Thank you for catching this Brian. It was meant to read Section 4.1.4 of >> RFC 6749. >> >> I've updated this in my local copy, will get posted in version 04. >> >> >>> >>> On Thu, Sep 12, 2019 at 8:40 AM Hannes Tschofenig < >>> Hannes.Tschofenig@arm.com> wrote: >>> >>>> Thanks for the correction; yes =E2=80=93 the most recent version is -0= 2 and I >>>> posted an old link. >>>> >>>> >>>> >>>> >>>> >>>> *From:* Eve Maler >>>> *Sent:* Donnerstag, 12. September 2019 16:16 >>>> *To:* Hannes Tschofenig >>>> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-0= 1 >>>> >>>> >>>> >>>> I think you mean >>>> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02? >>>> >>>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 <(425)%20345-6756= > >>>> >>>> >>>> On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig < >>>> Hannes.Tschofenig@arm.com > wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> We are starting a WGLC on the "OAuth 2.0 Incremental Authorization" >>>> draft. You can find the document here: >>>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01 >>>> >>>> >>>> >>>> Please review the document and provide feedback. >>>> >>>> >>>> >>>> The WGLC will end September 25th, 2019. >>>> >>>> >>>> >>>> Ciao >>>> >>>> Hannes & Rifaat >>>> >>>> IMPORTANT NOTICE: The contents of this email and any attachments are >>>> confidential and may also be privileged. If you are not the intended >>>> recipient, please notify the sender immediately and do not disclose th= e >>>> contents to any other person, use it for any purpose, or store or copy= the >>>> information in any medium. Thank you. >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> IMPORTANT NOTICE: The contents of this email and any attachments are >>>> confidential and may also be privileged. If you are not the intended >>>> recipient, please notify the sender immediately and do not disclose th= e >>>> contents to any other person, use it for any purpose, or store or copy= the >>>> information in any medium. Thank you. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly >>> prohibited.... If you have received this communication in error, pleas= e >>> notify the sender immediately by e-mail and delete the message and any = file >>> attachments from your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000000cada705a4c64800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Posting this to the list with Naveen's permission= , see his comment below, and my response:

On Thu, Nov 7, 2019 at = 12:51 AM Naveen Agarwal <na@ohauth.com> wrote:
Hi=C2=A0William,

One n= it.. on page 5 I think "requires" should be "required"<= /div>
"If later the user interacts wit=
h
   the calendar or contacts features then, and only then, should the
   requires scopes be requested. "

I've fixed this in my staged copy, will land in v= ersion 05.
=C2=A0
Separately I think it ma=
y be worth adding  somewhere (with more privacy conscious users and awareness)
that if authorization server does not show currently granted scopes, then=
 a user may assume that the current set of scopes 
are all they are granting to this client. Leading to privacy iss=
ues. 
<=
/div>

Thank you for your review Naveen, I a=
ppreciate your feedback.

I added a section to addr=
ess this topic, "Previously Granted Scopes" (in version 04). One =
challenge is that this advice can only apply to clients that can't be i=
mpersonated (like confidential clients), as otherwise the display could be =
inaccurate.
=C2=A0
Also a server could revalidate =
existing scopes and a user could deny them. A client should be able to hand=
le that.

=

It would be good to guide clients on this possibility, I agree. I adde=
d a new section "Handling Scope Reductions" (in version 04) to di=
scuss some of these possibilities and how they should be handled.

Regards,
William
=
=C2=A0
=

Thanks<=
/font>

Naveen<=
/font>


<=
div>

On Wed, Nov 6, 20=
19 at 5:15 PM William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrot=
e:

On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell <bcampbell=3D40pingi=
dentity.com@dmarc.ietf.org> wrote:
Just noticed that  something is =
missing in https://tools.ietf.org/html/draft=
-ietf-oauth-incremental-authz-02#section-5 where it has just, "(Se=
ction 4.1.4 of )" 

Thank you=
 for catching this Brian. It was meant to read Section 4.1.4 of RFC 6749.

I've updated this in my local copy, will get po=
sted in version 04.
=C2=A0

On Thu, Sep 12, 2019 at 8:40 AM Hannes Ts=
chofenig <Hannes.Tschofenig@arm.com> wrote:











Thanks for the correction; yes =E2=80=93 the most re=
cent version is -02 and I posted an old link.



=C2=A0


=C2=A0






From: Eve Maler <eve@xmlgrrl.com>


Sent: Donnerstag, 12. September 2019 16:16

To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>

Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-0=
1






=C2=A0


I think you mean=C2=A0<=
a href=3D"https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02=
" target=3D"_blank">https://tools.ietf.org/html/draft-ietf-oauth-incrementa=
l-authz-02?






Eve Maler (sent from =
my iPad) |=C2=A0cell +1 425 345 6756










On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com>=
 wrote:








Hi all,


=C2=A0


We are starting a WGLC on the "OAuth 2.0 Increm=
ental Authorization" draft. You can find the document here:<=
/u>


https://tools.ietf.org/html/dra=
ft-ietf-oauth-incremental-authz-01


=C2=A0


Please review the document and provide feedback.<=
/u>


=C2=A0


The WGLC will end September 25th, 2019.


=C2=A0


Ciao


Hannes & Rifaat


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











_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth







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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
....=C2=A0 If you have received this communication in error, please notify =
the sender immediately by e-mail and delete the message and any file attach=
ments from your computer. Thank you._____________________=
__________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






--0000000000000cada705a4c64800--


From nobody Sun May  3 15:57:18 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C947B3A093B for ; Sun,  3 May 2020 15:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-y_f8RZGeCr for ; Sun,  3 May 2020 15:57:16 -0700 (PDT)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 906053A090C for ; Sun,  3 May 2020 15:57:12 -0700 (PDT)
Received: by mail-oi1-x22e.google.com with SMTP id i13so5127422oie.9 for ; Sun, 03 May 2020 15:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ajoDH/O5sWTo1xaiZ16CW337OIU9ciOwjv2K/ke3zFo=; b=bopuFSkh3Smr5y6ZJEB3zL6JokvT6rpUxeEDGQ5KEZzuwXIqkjgXhF7+n8xd3wEqF0 BhPnS8avjnXGGEJRJegoFwAMQ4IkDAQZ70XKCadwOoYThFWFIItECwqaIXhqYZQ9ACKY FJn0qWFu35Zv08RdYhoR3fX9m9DImLZDu7OMDyPgj3nMf2NufG9Sso56oyrTHigvoZ2U e+VGcOVXhVdBETZuyGgTS1LIFyUbPNHjS43qWvOE+AmWJxjEJRbHKfsRwVo/ci+4Iadq kJ+8mGdPyXezkSN69e00FSsXn/IohFhnl6r39DZ2tFvIU6kA5oXfFZrXDjhnkmIoT+b1 LpgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ajoDH/O5sWTo1xaiZ16CW337OIU9ciOwjv2K/ke3zFo=; b=q9jj+j/H5IysrjotFTYBkemS3UYxJe0nSptkPJyyq6IBca7NQpPZEPgcjJZLAizw09 YHgdZ9TtbtiBZ6mcVlv1rM93UfhiisBl/a7ga4SL/Obf9Anc7sEbOc2Jxe2VQWi3l0lI RQJot+PujV9TK3nQH1DLs/dPmHrFrw410TY1mxiL0HkSM9ZOIVhXb7m28COfpWHGq2NR gh3AOJtaRcb5oi7ekvUa2VOrpFpC+4S5aU8SUEOs1O2xL0atZz3bdJdX5Mtu4sod+xGa rrUiIzobvdVHUBYiD5xAvxXWiCGg3r3plVS8c92TYtSk8mWHLNG46PHdKmOmj/k/aAwn T0XQ==
X-Gm-Message-State: AGi0PubbVMEs1cBKjycgjQg3fn2WKzxt3sfbXSlJpUWgN3oXsmjCK1oY H3AISfOpLCCNRAMclEVEsrD4nBnSMiBmh+1mRxJJIp1T
X-Google-Smtp-Source: APiQypIAe4Apdrm6GDJRHeZF1Q6WrbsVfXRJHkbX3hBIosNIpkIe2YktrRIDpofHoKypNbIX0NUDjU0+Y1xswVnaAsQ=
X-Received: by 2002:aca:b6c2:: with SMTP id g185mr7114892oif.156.1588546631186;  Sun, 03 May 2020 15:57:11 -0700 (PDT)
MIME-Version: 1.0
References: <158854592426.14672.16620287539138925587@ietfa.amsl.com>
In-Reply-To: <158854592426.14672.16620287539138925587@ietfa.amsl.com>
From: William Denniss 
Date: Sun, 3 May 2020 15:56:58 -0700
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000a9904105a4c65598"
Archived-At: 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-incremental-authz-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 03 May 2020 22:57:18 -0000

--000000000000a9904105a4c65598
Content-Type: text/plain; charset="UTF-8"

In this version, I addressed review feedback from Naveen and Aaron, which
resulted in added some new sections "Previously Granted Scopes" and
"Handling Scope Reductions" containing some advice for implementors,
 and a clarification of the OAuth metadata.

I also defined a new OAuth error code, "overbroad_scope" to have a proper
way for servers to deny requests for this reason (was already defined in
"Preventing Overbroad Authorization Requests", but didn't have a unique
error code defined).

I will be discussing these changes and the document as a whole tomorrow. I
realize this version is posted very close to that meeting, and so I do not
expect anyone to read the changes before my presentation. I will take a
minute then to briefly outline these changes at that time.

Best,
William

---------- Forwarded message ---------
From: 
Date: Sun, May 3, 2020 at 3:45 PM
Subject: New Version Notification for
draft-ietf-oauth-incremental-authz-04.txt
To: William Denniss 



A new version of I-D, draft-ietf-oauth-incremental-authz-04.txt
has been successfully submitted by William Denniss and posted to the
IETF repository.

Name:           draft-ietf-oauth-incremental-authz
Revision:       04
Title:          OAuth 2.0 Incremental Authorization
Document date:  2020-05-03
Group:          oauth
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-ietf-oauth-incremental-authz-04.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/
Htmlized:
https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-incremental-authz-04

Abstract:
   OAuth 2.0 authorization requests that include every scope the client
   might ever need can result in over-scoped authorization and a sub-
   optimal end-user consent experience.  This specification enhances the
   OAuth 2.0 authorization protocol by adding incremental authorization,
   the ability to request specific authorization scopes as needed, when
   they're needed, removing the requirement to request every possible
   scope that might be needed upfront.




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

--000000000000a9904105a4c65598
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


In this version, I addressed review feedback from Naveen a=
nd Aaron, which resulted in added some new sections "Previously Grante=
d Scopes" and "Handling Scope Reductions" containing some ad=
vice for implementors,
=C2=A0and a clarification of the OAuth metadata.=


I also defined a new OAuth error code, "over=
broad_scope" to have a proper way for servers to deny requests for thi=
s reason (was already defined in "Preventing Overbroad Authorization R=
equests", but didn't have a unique error code defined).
=

I will be discussing these changes and the document as a who=
le tomorrow. I realize this version is posted very close to that meeting, a=
nd so I do not expect anyone to read the changes before my presentation. I =
will take a minute then to briefly outline these changes at that time.

Best,
William

---------- Forwarded messa=
ge ---------
From: <internet-drafts@ietf.org>
Date: Sun, May 3, =
2020 at 3:45 PM
Subject: New Version Notification for draft-ietf-oauth-i=
ncremental-authz-04.txt
To: William Denniss <wdenniss@google.com>




A new version of I-D, draft-ietf-oauth-incremental-authz-04.txt

has been successfully submitted by William Denniss and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-incremental-=
authz

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Incremental Authorizatio=
n

Document date:=C2=A0 2020-05-03

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-oau=
th-incremental-authz-04.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-auth=
z/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-=
authz

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-inc=
remental-authz-04



Abstract:

=C2=A0 =C2=A0OAuth 2.0 authorization requests that include every scope the =
client

=C2=A0 =C2=A0might ever need can result in over-scoped authorization and a =
sub-

=C2=A0 =C2=A0optimal end-user consent experience.=C2=A0 This specification =
enhances the

=C2=A0 =C2=A0OAuth 2.0 authorization protocol by adding incremental authori=
zation,

=C2=A0 =C2=A0the ability to request specific authorization scopes as needed=
, when

=C2=A0 =C2=A0they're needed, removing the requirement to request every =
possible

=C2=A0 =C2=A0scope that might be needed upfront.









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








--000000000000a9904105a4c65598--


From nobody Sun May  3 16:54:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A02B3A0975 for ; Sun,  3 May 2020 16:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zom9BnhWVZSx for ; Sun,  3 May 2020 16:54:16 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF9F3A096B for ; Sun,  3 May 2020 16:54:15 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id j4so7471767otr.11 for ; Sun, 03 May 2020 16:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5J2Y9nqMC6D2Qrlf3mNDyi1HV3hLIRkf4potUQWQ+/g=; b=kT/0/c7SrwsDfmZrESikVsMhnhu8GVwnfPWcwdawluBUJ7KctVwWLYNFMGbOtFZ1b9 xLVSf64GgsAsDTI3UIYJgo/dOAZtlOUt8gUNZaZQabTHrHq0EmDGWU00/+/duJKb8HT8 xxdsrmzbMZ96yqRQUh47HyNs5j/xGvwmZ/tRI0qhWhwWKMQJALSss5YgD3zpUBtzN0sK b3U1i7leToK0PhDVVFrmp9RFDfWFRlKUR7mcwmvNSxbABJXCUFwCTjyIyxZsFi2R7LCz 27VRr45jmbKwqD30OVoLKjJPuYEDHWID+z7rHfaIoNa98yNPBnob2IA3F4HBIYdmlhn4 LAjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5J2Y9nqMC6D2Qrlf3mNDyi1HV3hLIRkf4potUQWQ+/g=; b=tzVbwB64pkjDkLf279GBpozVH5eX/wyVJ5XMUascVcxq8DQWmG+Mng2sn0yPkwgz9M zdyBPdavpH75kSGkLOu/aAAtJUyl+4a7noPH63FrBrBdijtA2e95im1+TYNunJupslao g2iDHoT7jp7WEFQFp46ZAEF/phU2K73iUpdBlMiO8JygXCXW3k8uvACSLlFOtNmtRnJl j4Ny1OTrSYmaXUCiIG329C1zZPRBeCIZ7rGi/M346TzNBdIWVcbePhslHfzfzSxA4bYK 3EO9r/3okWb6rtk0Wqjh0pBYKhts25rp/aa5tp0eCs4k2GXjLcb6brBIHMf40dzjJ6to Q3jA==
X-Gm-Message-State: AGi0Pua4Jb63X+VVDHQVY2ePbNV/xjODMhzPUFcDVXakfKsTQM+jS2kL gNSlA7y269Sln0vU4LKGJOHafJw2O9y8VzzI6L1XOw==
X-Google-Smtp-Source: APiQypKuQfrnk9pOLmVeOeQMG7t0JM3QAoYhPR9UaCUCdBlSEKvAgLpMwOruecwi/fktBWSH5VJ9esnQFrbOf56bVDA=
X-Received: by 2002:a9d:7ada:: with SMTP id m26mr11717253otn.181.1588550054696;  Sun, 03 May 2020 16:54:14 -0700 (PDT)
MIME-Version: 1.0
References: <158835743733.12112.7484502726888997082@ietfa.amsl.com> 
In-Reply-To: 
From: William Denniss 
Date: Sun, 3 May 2020 16:54:02 -0700
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000b8276805a4c72185"
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 03 May 2020 23:54:18 -0000

--000000000000b8276805a4c72185
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Brian, et. al,

I reviewed the document. Overall I think the concept is clearly
communicated, both the need, and how it is implemented. It was easy to
read, and concise. Great work!

Some comments and nits:

=C2=A7 1:
(nit) "DPoP" should be defined on first use in the body of the document, in
my opinion.

=C2=A7 3:

I don't follow this why the sentence "For confidential clients, refresh
tokens are bound to the "client_id", which is more flexible than binding it
to a particular public key." belongs in this explanation of the diagram. Is
it indicating that DPoP is not required for confidential clients? If the
sentence was deleted / moved elsewhere in the doc, would it alter the
meaning of the diagram?

I wonder if the diagram would be simpler with less optionality (e.g. public
/ confidential separated into 2 diagrams, if they behave differently), or
maybe just kept as 1 simple diagram, with any optionality described later.
Generally I think these kind of overview diagrams (which are extremely
helpful, and now I must go add one to my own draft) are best if they give
an overview of the protocol without trying to document the entire
specification, or justify why different decisions are made.

=C2=A7 4.1 figure 2

(nit) When showing a decoded JWT with the signature dropped, I think it's a
good idea to first present the full encoded JWT. Someone who is new to JWT
may not realize that this data has a signature (or even that it is encoded
at all), since it was dropped already, while showing the before/after can
make this clear. Not essential, I just think it would help readers. Having
this also sets the scene for later when encoded JWTs are used in example
request headers.

=C2=A7 4.1, below figure 2:

Regarding "Note: To keep DPoP simple to implement, only the HTTP method and
URI
   are signed in DPoP proofs."

I found this confusing as the entire JWT is signed, and the signature
covers the whole JWT and not just those 2 claims. I get that since the JWT
only meaningfully contains the HTTP method and URI that the statement is
effectively true, but I would rephrase. Something along the lines of:

"Of the HTTP headers in the request, only the HTTP method and URI are
included in the DPoP JWT, and therefore only these 2 headers of the request
are covered by the DPoP proof"

(nit) I would also drop the "To keep DPoP simple to implement" here, and
maybe move any discussion about the design trade-offs to the security
considerations (9.4).

=C2=A7 5

(nit) Expand "AS" on first use (or better: just say "authorization server"
and skip the acronym in this case, as "AS" is insider lingo IMO)

=C2=A7 5

Regarding "If a refresh token is issued to a public client"...

What about when it's issued to the confidential client? I think when
specific behavior is documented for one client type, it's probably good to
at least mention how the other types behave.

I think this could be clarified here. In fact, I wonder if the text I
highlighted earlier from =C2=A7 3 might belong here.

=C2=A7 8

(nit) Suggest moving to an Appendix

=C2=A7 9.1

(nit) "up to a few seconds", I would just say "e.g. a few seconds in the
future". Seems odd to specify an upper bound on a non-exact number.

=C2=A7 9.4

" DPoP does not ensure the integrity of the payload or headers of
   requests.  The signature of DPoP proofs only contains the HTTP URI
   and method, but not, for example, the message body or other request
   headers."

Again, I find this an awkward phrase, "the signature of the DPoP proofs
only contains the HTTP URI and method", and I think it' better to talk
about the JWT only containing these claims, and the signature therefore
only signing those claims. Also, (nit) does a proof "contain" something, or
more accurately cover/sign something?

William




On Fri, May 1, 2020 at 12:04 PM Brian Campbell  wrote:

> I've pushed out a -01 revision of DPoP hopefully allowing folks enough
> time to read it before the interim meeting on Monday (apologies that it
> wasn't sooner but the edits took longer than expected or hoped). For ease
> of reference the changes in this revision are summarized below. There are=
,
> of course, still outstanding issues and discussion points that I hope to
> make some progress on during the interim meeting on Monday.
>
>    -01
>
>    *  Editorial updates
>    *  Attempt to more formally define the DPoP Authorization header
>       scheme
>    *  Define the 401/WWW-Authenticate challenge
>    *  Added "invalid_dpop_proof" error code for DPoP errors in token
>       request
>    *  Fixed up and added to the IANA section
>    *  Added "dpop_signing_alg_values_supported" authorization server
>       metadata
>    *  Moved the Acknowledgements into an Appendix and added a bunch of
>       names (best effort)
>
> ---------- Forwarded message ---------
> From: >
> Date: Fri, May 1, 2020 at 12:24 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
> To: Torsten Lodderstedt , David Waite <
> david@alkaline-solutions.com>, John Bradley , Brian
> Campbell , Daniel Fett ,
> Michael Jones 
>
>
>
> A new version of I-D, draft-ietf-oauth-dpop-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name:           draft-ietf-oauth-dpop
> Revision:       01
> Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the
> Application Layer (DPoP)
> Document date:  2020-05-01
> Group:          oauth
> Pages:          22
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop=
-01
>
> Abstract:
>    This document describes a mechanism for sender-constraining OAuth 2.0
>    tokens via a proof-of-possession mechanism on the application level.
>    This mechanism allows for the detection of replay attacks with access
>    and refresh tokens.
>
>
>
>
> 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
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000b8276805a4c72185
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Brian, et. al,

I reviewed=
 the document. Overall I think the concept is clearly communicated, both th=
e need, and how it is implemented. It was easy to read, and concise. Great =
work!

Some comments and nits:

=C2=A7 1:
(nit) "DPoP" should be defined on fi=
rst use in the body of the document, in my opinion.

=C2=A7 3:

I don't follow this why the senten=
ce "For confidential clients, refresh tokens are bound to the "cl=
ient_id", which is more flexible than binding it to a particular publi=
c key." belongs in this explanation of the diagram. Is it indicating t=
hat DPoP is not required for confidential clients? If the sentence was dele=
ted / moved elsewhere in the doc, would it alter the meaning of the diagram=
?

I wonder if the diagram would be simpler with le=
ss optionality (e.g. public / confidential separated into 2 diagrams, if th=
ey behave differently), or maybe just kept as 1 simple diagram, with any op=
tionality described later. Generally I think these kind of overview diagram=
s (which are extremely helpful, and now I must go add one to my own draft) =
are best if they give an overview of the protocol without trying to documen=
t the entire specification, or justify why different decisions are made.

=C2=A7 4.1 figure 2

(ni=
t) When showing a decoded JWT with the signature dropped, I think it's =
a good idea to first present the full encoded JWT. Someone who is new to JW=
T may not realize that this data has a signature (or even that it is encode=
d at all), since it was dropped already, while showing the before/after can=
 make this clear. Not essential, I just think it would help readers. Having=
 this also sets the scene for later when encoded JWTs are used in example r=
equest headers.

=C2=A7=C2=A04.1, below figure 2:

Regarding "Note: To keep DPoP simple to implem=
ent, only the HTTP method and URI
=C2=A0 =C2=A0are signed in DPoP proo=
fs."

I found this confusing as the entire JWT is si=
gned, and the signature covers the whole JWT and not just those 2 claims. I=
 get that since the JWT only meaningfully contains the HTTP method and URI =
that the statement is effectively true, but I would rephrase. Something alo=
ng the lines of:

"Of the HTTP headers in the =
request, only the HTTP method and URI are included in the DPoP JWT, and the=
refore only these 2 headers of the request are covered by the DPoP proof&qu=
ot;

(nit) I would also drop the "To keep DPoP=
 simple to implement" here, and maybe move any discussion about the de=
sign trade-offs to the security considerations (9.4).

<=
div>=C2=A7 5

(nit) Expand "AS" on fi=
rst use (or better: just say "authorization server" and skip the =
acronym in this case, as "AS" is insider lingo IMO)
=C2=A7 5

Regarding "If a refr=
esh token is issued to a public client"...

Wh=
at about when it's issued to the confidential client? I think when spec=
ific behavior is documented for one client type, it's probably good to =
at least mention how the other types behave.

I thi=
nk this could be clarified here. In fact, I wonder if the text I highlighte=
d earlier from =C2=A7 3 might belong here.

=C2=A7 =
8

(nit) Suggest moving to an Appendix

=C2=A7 9.1

(nit) "up to =
a few seconds", I would just say "e.g. a few seconds in the futur=
e". Seems odd to specify an upper bound on a non-exact number.

=C2=A7 9.4

" DPoP does =
not ensure the integrity of the payload or headers of
=C2=A0 =C2=A0reque=
sts.=C2=A0 The signature of DPoP proofs only contains the HTTP URI
=C2=
=A0 =C2=A0and method, but not, for example, the message body or other reque=
st
=C2=A0 =C2=A0headers."

Again, I fin=
d this an awkward phrase, "the signature of the DPoP proofs only conta=
ins the HTTP URI and method", and I think it' better to talk about=
 the JWT only containing these claims, and the signature therefore only sig=
ning those claims. Also, (nit) does a proof "contain" something, =
or more accurately cover/sign something?

William




On Fri, May 1, 2020 at 12:0=
4 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
I'=
ve pushed out a -01 revision of DPoP hopefully allowing folks enough time t=
o read it before the interim meeting on Monday (apologies that it wasn'=
t sooner but the edits took longer than expected or hoped). For ease of ref=
erence the changes in this revision are summarized below. There are, of cou=
rse, still outstanding issues and discussion points that I hope to make som=
e progress on during the interim meeting on Monday.

=C2=A0=C2=A0 -01

=C2=A0 =C2=A0* =C2=A0Editorial updates
=
=C2=A0 =C2=A0* =C2=A0Attempt to more formally define the DPoP Authorization=
 header
=C2=A0 =C2=A0 =C2=A0 scheme
=C2=A0 =C2=A0* =C2=A0Define the 4=
01/WWW-Authenticate challenge
=C2=A0 =C2=A0* =C2=A0Added "invalid_d=
pop_proof" error code for DPoP errors in token
=C2=A0 =C2=A0 =C2=A0=
 request
=C2=A0 =C2=A0* =C2=A0Fixed up and added to the IANA section
=
=C2=A0 =C2=A0* =C2=A0Added "dpop_signing_alg_values_supported" au=
thorization server
=C2=A0 =C2=A0 =C2=A0 metadata
=C2=A0 =C2=A0* =C2=
=A0Moved the Acknowledgements into an Appendix and added a bunch of
=C2=
=A0 =C2=A0 =C2=A0 names (best effort)

---------- Forwarded message -----=
----
From: <internet-drafts@ietf..org>
Date: F=
ri, May 1, 2020 at 12:24 PM
Subject: New Version Notification for draft-=
ietf-oauth-dpop-01.txt
To: Torsten Lodderstedt <torsten@lodderstedt.net>, Da=
vid Waite <david@alkaline-solutions.com>, John Bradley <ve7jtb@ve7jtb.com>, Brian Ca=
mpbell <=
bcampbell@pingidentity.com>, Daniel Fett <mail@danielfett.de>, Michael Jones =
<mbj@microsoft.co=
m>




A new version of I-D, draft-ietf-oauth-dpop-01.txt

has been successfully submitted by Brian Campbell and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dpop

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Demonstration of Proof-o=
f-Possession at the Application Layer (DPoP)

Document date:=C2=A0 2020-05-01

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.t=
xt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http=
s://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool=
s.ietf.org/html/draft-ietf-oauth-dpop-01

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https=
://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01



Abstract:

=C2=A0 =C2=A0This document describes a mechanism for sender-constraining OA=
uth 2.0

=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application =
level.

=C2=A0 =C2=A0This mechanism allows for the detection of replay attacks with=
 access

=C2=A0 =C2=A0and refresh tokens.









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










<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
..=C2=A0 If you have received this communication in error, please notify th=
e sender immediately by e-mail and delete the message and any file attachme=
nts from your computer. Thank you._______________________=
________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000b8276805a4c72185--


From nobody Sun May  3 22:59:37 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3121E3A0CBA for ; Sun,  3 May 2020 22:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGV9ocuq7Oq9 for ; Sun,  3 May 2020 22:59:32 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E2B3A0CB9 for ; Sun,  3 May 2020 22:59:31 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0445xOxZ012423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 May 2020 01:59:26 -0400
Date: Sun, 3 May 2020 22:59:23 -0700
From: Benjamin Kaduk 
To: Denis 
Cc: Vittorio Bertocci , "oauth@ietf.org" 
Message-ID: <20200504055923.GH27494@kduck.mit.edu>
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 05:59:35 -0000

Hi Denis,

You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation.  In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.

Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works.  I think you do everyone a disservice for
attempting to suggest that this document should do so.

Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.

On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
> Hello Vittorio,
> 
> Your reply was amazingly fast. Responses are between the lines.
> 
> > Thanks Denis for the thorough commentary.
> >
> > /> The title of this spec./
> >
> > Fixed, thanks!
> >
> 
> > /> The client MUST NOT inspect the content of the access token/
> >
> >
> > This is really a sticky point. I really want to acknowledge your PoV 
> > on this, but at the same time I found this to be one of the biggest 
> > sources of issues
> > in the use of JWT for access tokens hence I feel we really need to 
> > give solid guidance here. Let me expand further on the reasoning 
> > behind it,
> > and perhaps we can get to language that satisfies both PoVs.
> >
> >
> > To me the key point is that clients should not write /code/ that 
> > inspects access tokens. Taking a dependency on the ability to do so is 
> > ignoring fundamental information
> > about the architecture and relationships between OAuth roles, and 
> > suggests an ability of the client to understand the semantic of the 
> > content that cannot be assumed
> > in the general case. I expanded on the details in my former reply to 
> > you on this topic, I would recommend referring to it.
> >
> > Clients violating this simple principle has been one of the most 
> > common sources of production issues I had to deal with in the past few 
> > years, and one of the hardest
> > to remediate given that clients are hard to update and sometimes the 
> > things they relied on were irremediably lost. This is why I am 
> > inclined to put in here strong language.
> >
> > That said: I have nothing against client developers examining a 
> > network trace and drawing conclusions based on the content of what 
> > they see. That doesn’t create any hard
> > dependencies and has no implications in respect to changes in the 
> > solution behavior. However I am not sure how to phrase that in the 
> > specification, given that referring
> > to the client inevitably refers to its code. I am open to suggestions.
> >
> First of all, a "*MUST NOT* "should not be placed in a privacy 
> considerations section, but in the main body of the document.
> The goal of a privacy considerations section is to provide explanations, 
> but not to introduce additional requirements.

That's not actually a requirement.  In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.

> Then after, since this section is about privacy considerations, it is 
> important to refer to an ISO standard that has been published 9 years ago.

Is it?  I don't see much precedent for IETF documents referencing this ISO
standard.  If it's so important you'd think that we'd have been citing it
with regularity.  Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.

> It is ISO 29100 (Information technology — Security techniques — Privacy 
> framework). Most of the ISO standards need to be bought.
> However, there are a few exceptions and this standard can be freely 
> downloaded from the ISO web site, if you accept some conditions,
> using this URL:
> 
>     https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
> 
> ISO 29100, even if it is outdated on some aspects (it only deals with 
> two entities), identifies ten principles (See Table 3).
> 
>     1. Consent and choice
> 
>     2. Purpose legitimacy and specification
> 
>     3. Collection limitation
> 
>     4. Data minimization
> 
>     5. Use, retention and disclosure limitation
> 
>     6. Accuracy and quality
> 
>     7. Openness, transparency and notice
> 
>     8. Individual participation and access
> 
>     9. Accountability
> 
>     10. Information security
> 
>     11. Privacy compliance
> 
> If the client is unable to inspect the token, then openness and 
> transparency do not exist any more.
> 
> Since there is no formal protocol in OAuth 2.0  for "consent and 
> choice", the only way for a client for denying its consent is to inspect 
> the token
> and to stop its transmission if the content of the token is not 
> considered to be adequate for it.
> 
> Since you are open to suggestions, would you please reconsider the text 
> I proposed: it simply states that if the client wants to inspect the token,
> it will not necessarily be in a position to do it. It is simply a 
> warning, but this warning does not prevent the client to attempt to 
> inspect the token .
> 
> I will go one step further: if the client wants to inspect the token and 
> if the format of the token is unknown to the client, then the client 
> will simply
> stop its further transmission. For some clients, preserving their 
> privacy may be more important than performing an access to a RS.

That may be true, but I agree with Vittorio that this document needs to
strongly discourage clients from doing so, since they would be breaking a
protocol invariant if they do.

Thanks,

Ben

> > >  3)…
> >
> > I have a pretty hard time following the chain of reasoning in this 
> > section. Let me attempt to tackle it to the best of my understanding.
> >
> > I think the key might be
> >
> > /> a client should be able to choose whether it wishes the sub claim 
> > to contain [..]
> >
> > /
> >
> > I don’t think that should be a choice left to the client. In business 
> > systems, my experience is that the type of identifiers to be used 
> > (when the IdP gives any choice at all)
> >  is established at resource provisioning time. I am not aware of 
> > mechanisms thru which a client signals the nature of the identifier to 
> > be used, nor that would be fully
> > feasible (the resource knows what it needs to perform its function).
> >
> Consent and choice is the first of the ten privacy principles. Since 
> OAuth has not been constructed taking into considerations this privacy 
> principle,
> it is quite "normal" that you don't observe protocols able to do it at 
> the present time.
> 
> > Furthermore:
> >
> > /> which has nothing to do with uniqueness since the value changes for 
> > every generated token.
> >
> > /
> >
> > Again, this is something that was touched on in my former reply to 
> > your message. As long as an identifier identifies one resource only, 
> > it satisfies uniqueness. It doesn’t have to be a singleton.
> >
> It is a matter of interpretation. I stick to the definition given in RFC 
> 7519 (section 4.1.2):
> 
> *T**he subject value MUST either be scoped to be locally unique in the 
> context of the issuer or be globally unique.*
> 
> However, the "context of the issuer" is left undefined.
> 
> > Finally, the scope is optional (for good reasons: 1^st party and non 
> > delegation scenarios don’t require it) hence it cannot be relied upon 
> > for properties that should hold in every scenario.
> >
> I would not say that the scope request parameter is a nice way to choose 
> which attributes should be placed in a JWT. However, considering the 
> limitations placed
> in this document, it is the ONLY way to do. In my email sent before the 
> virtual meeting, I wrote: "Allowing a client to only specify a scope and 
> a resource is very restrictive".
> 
> Clause 2.2.2 (second paragraph) states:
> 
> ***This profile does not introduce any mechanism for a client to**
> ******directly request the presence of specific claims in JWT access**
> ******tokens*, as the authorization server can determine what additional
> claims are required by a particular resource server by taking in
> consideration the client_id of the client, the scope and the resource
> parameters included in the request.
> 
> Currently, the client has no control of the claims that will be placed 
> in a JWT and further more the current wording of privacy consideration 
> section
> prevents the client to have any inspection of the attributes that have 
> been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not 
> fulfilled.
> 
> There are more implications. If, in the future, a mechanism is defined 
> to allow the client to choose the type of the attributes that should be 
> placed in a JWT,
> then the "sub" claim is insufficient. Taking into consideration my 
> previous email, four types of attributes types would need to be specified:
> 
> The client should be able to choose whether it wishes a claim that contains:
> 
>   *      a global unique identifier for all ASs ("globally unique"),
>   *      a unique identifier for each AS ("locally unique in the context
>     of the issuer"),
>   *      a different pseudonym for each RS, or
>   *      a different pseudonym for each authorization token request.
> 
> Clause 2.2.2 states:
> 
> *   the authorization server can determine what additional**
> ******claims are required by a particular resource server* by taking in
> consideration the client_id of the client, the scope and the resource
> parameters included in the request.
> 
> I don't believe this is true in general. Considering its privacy 
> preferences, only the client may know what is appropriate: not the AS, 
> neither the RS.
> 
> > In summary: per the preceding thread on this topic, the consensus was 
> > that varying the sub content was a satisfactory way of protecting 
> > against correlation.
> >
> "/if all you have is a hammer, everything looks like a nail/".
> 
> When the only parameter that can be used is the "sub" claim, then the 
> only solution is to place everything into it.
> 
> > I don’t a gree that clients should have a mechanism to request 
> > different sub flavors, as that decision should be done out of band by 
> > the AS and RS; and the scope isn’t always available anyway.
> >
> While it would be nice to have such a mechanism, we are not going to 
> define such a mechanism during a second WGLC.
> 
> The privacy considerations section should only inform the readers about 
> the limitations of the protocol in terms of privacy.
> I have proposed text to address the point. If you would prefer a 
> different wording to address this point, please make another proposal.
> 
> > /> targeting of access tokens/
> >
> > Let me think about that a bit longer.
> >
> > I acknowledge that the decision of including an audience has the 
> > effect of letting the AS track when the client accesses a particular 
> > resource,
> > but at the same time that’s completely mainstream and very much by 
> > design in a very large number of cases. As such, I find the language
> > you are suggesting to be potentially confusing, as it positions this 
> > as an exception vs a privacy protecting mainstream that is in fact not 
> > common,
> > and ascribes to the client more latitude than I believe is legitimate 
> > to expect or grant.
> >
> > I’ll try to come up with concise language that clarifies to the reader 
> > that the current mechanism does allow AS tracking.
> >
> Please do so.
> 
> Denis
> 
> > *From: *OAuth  on behalf of Denis 
> > 
> > *Date: *Wednesday, April 29, 2020 at 09:12
> > *To: *"oauth@ietf.org" 
> > *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> > for OAuth 2.0 Access Tokens"
> >
> > You will find four comments numbered 1) to 4).
> >
> > *1) *The title of this spec. is:
> >
> > JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
> >
> > So, this spec. is supposed to be targeted to OAuth *2.0. * However, 
> > the header at the top of the page omits to mention it.
> >
> > Currently, it is :
> >
> > Internet-Draft OAuth Access Token JWT Profile           April 2020
> >
> > It should rather be:
> >
> > Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020
> >
> > *2)* The following text is within section 6.
> >
> > The client MUST NOT inspect the content of
> > the access token: the authorization server and the resource server
> > might decide to change token format at any time (for example by
> > switching from this profile to opaque tokens) hence any logic in the
> > client relying on the ability to read the access token content would
> > break without recourse.
> > Nonetheless, authorization servers should
> > not assume that clients will comply with the above.
> >
> > It is of a primary importance that clients MAY be able to inspect 
> > tokens before transmitting them.
> > The "MUST NOT" is not acceptable.
> >
> > The above text should be replaced with:
> >
> > Reading the access token content may be useful for the user to verify 
> > that
> > the access token content matches with its expectations. However,
> > the authorization server and the resource server might decide to 
> > change the
> > token format at any time.  Thus, the client should not expect to 
> > always be
> > in a position to read the access token content.
> >
> > The remaining of the text about this topic is fine.
> >
> >
> > *3) *The next topic is about the sub claim.
> >
> > The text states:
> >
> > Although the ability to correlate requests might be required by
> > design in many scenarios, there are scenarios where the authorization
> > server might want to prevent correlation to preserve the desired
> > level of privacy. Authorization servers should choose how to assign
> > sub values according to the level of privacy required by each
> > situation.
> >
> > I have a set of questions:
> >
> >  1. How can authorization servers choose how to assign sub values
> >     according to the level of privacy required "by each situation" ?
> >  2. How can authorization servers know the level of privacy required
> >     "by each situation" ?
> >  3. How can the users be informed of the level of privacy required "by
> >     each situation" ?
> >  4. How can the users *consent* with the level of privacy required "by
> >     each situation" ?
> >
> > Currently, the request MUST include either a resource parameter or an 
> > aud claim parameter, while it MAY include a scope parameter.
> >
> > The syntax of the scope parameter is a list of space-delimited, 
> > case-sensitive strings (RFC 6749). It is thus subject to private 
> > agreements
> > between clients and Authorization Servers. Since the scope is being 
> > returned, it is a primary importance that the returned scope matches
> > with its expectations before transmitting the token to a Resource Server.
> >
> > In theory, a client should be able to choose whether it wishes the sub 
> > claim to contain :
> >
> >   * a global unique identifier for all ASs ("globally unique"),
> >   * a unique identifier for each AS ("locally unique in the context of
> >     the issuer"),
> >   * a different pseudonym for each RS, or
> >   * a different pseudonym for each authorization token request.
> >
> > The only variable parameter that it can use for this purpose in the 
> > token request is the scope parameter.
> >
> > RFC 7519 states is section 4.1.2:
> >
> > The subject value MUST either be scoped to be locally unique in the 
> > context of the issuer
> > or be globally unique.
> >
> > It is quite hard to recognize that the sub claim is able to carry a 
> > different pseudonym for each RS, i.e. for case (c), or
> > a different pseudonym for each authorization token request, i.e. for 
> > case (d), which has nothing to do with uniqueness
> > since the value changes for every generated token.
> >
> > This has implications about the following text:
> >
> > For instance: if a solution requires preventing tracking
> > principal activities across multiple resource servers, the
> > authorization server should ensure that JWT access tokens meant for
> > different resource servers have distinct sub values that cannot be
> > correlated in the event of resource servers collusion.
> >
> > Since it addresses case (c).
> >
> > and also about the following text:
> >
> > 4.b) Similarly: if a solution requires preventing a resource server from
> > correlating the principal’s activity within the resource itself, the
> > authorization server should assign different sub values for every JWT
> > access token issued.
> >
> > Since it addresses case (d).
> >
> > This means that the current text placed in the privacy considerations 
> > section was a good attempt to address the case,
> > but that the text needs to be revised.
> >
> > Proposed text replacement for all the previously quoted sentences:
> >
> > According to RFC 7519 (4.1.2): The subject value MUST either be scoped 
> > to be locally unique in the context of the issuer or be globally unique.
> >
> > When the sub claim contains a globally unique identifier, this allows 
> > to correlate principal activities across multiple resource servers, 
> > while in addition,
> > this globally unique identifier may also allow to correlate the 
> > principal activities on servers where no access has been performed by 
> > the principals
> > to these servers but where the same globally unique identifiers are 
> > being used by these servers.
> >
> > When the sub claim contains a locally unique identifier in the context 
> > of the issuer, this also allows the tracking of principal activities 
> > across multiple resource servers.
> >
> > The scope request parameter is the only way to influence on the 
> > content of the sub claim parameter. Its meaning is subject to a 
> > private agreement
> > between the client and the AS, which means that the use of the scope 
> > parameter is the only way to choose between a locally unique identifier
> > in the context of the issuer or a globally unique identifier.
> >
> > Since the scope parameter is being returned, it is a primary 
> > importance that the returned scope matches with the expectations of 
> > the client before transmitting
> > the token to a Resource Server.
> >
> > However, there are other cases where the client would like to be able 
> > to choose whether it wishes the sub claim to contain :
> >     - a different pseudonym for each RS so that different resource 
> > servers will be unable to correlate its activities, or
> >     - a different pseudonym for each authorization token request, so 
> > that the same resource server cannot correlate its activities 
> > performed at different instant of time.
> >
> > Considering the semantics of the sub claim, these two cases cannot be 
> > currently supported.
> >
> >
> > *4) *The next topic is about the targeting of access tokens
> >
> > Text had been proposed before the last conference call. Then, the 
> > topic has been presented at the very end of the last conference call, 
> > but no text has been included
> > in the next draft.
> >
> > Here is a revised text be included in the privacy considerations section:
> >
> > For security reasons, some clients may be willing to target their 
> > access tokens but, for privacy reasons, may be unwilling to disclose 
> > to Authorization Servers
> > an identification of the Resource Servers they are going to access, so 
> > that Authorization Servers will be unable to know which resources 
> > servers are being accessed.
> > The disclosure of the Resource Servers names allows the Authorization 
> > Servers to list all the Resource Servers being access by all its users 
> > and in addition to list pairs
> > of (Principal, Resource Servers) which allow to trace all the users 
> > accesses to Resource Servers performed through a given Authorization 
> > Server. When a token is targeted,
> > this profile does not contain provisions to address these two threats.
> >
> > Denis
> >
> >     Hi all,
> >
> >     This is a second working group last call for "JSON Web Token (JWT)
> >     Profile for OAuth 2.0 Access Tokens".
> >
> >     Here is the document:
> >
> >     https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
> >
> >     Please send your comments to the OAuth mailing list by April 29, 2020.
> >
> >     Regards,
> >
> >      Rifaat & 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


From nobody Mon May  4 00:36:52 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA79B3A0D1F for ; Mon,  4 May 2020 00:36:50 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjo2s5kGRxpF for ; Mon,  4 May 2020 00:36:49 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A583A0D1E for ; Mon,  4 May 2020 00:36:48 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id b188so15629574qkd.9 for ; Mon, 04 May 2020 00:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to; bh=Jg75dROtWgyWOZlQ6FKCQof9SLCUskha8eUAEJwUBnY=; b=oMyaQJYgCy6wkUJHot5FOU4YXC3JQc7mlSFVNLkPYUl939KC/EW79dfDt6gypa6oHw Jj2nXym4qQX9prRLVGkGTHfhPSvnq4UP7lssvYWtcFm+8+eyppVaeK2Kyobgk7C70HCs zDTcktptNPZziUdPBgKYUtqnu2GiyrwbCZFvPA4mPPVdF7q/1BoChjgAN73XamNwAYQV SAl4htCbUGBLJ1sqdX7bYnMcKeBMhcKLK8rLI4dfpsYI3Ab4iC8eHsv0fPcONdd7eMp6 ngeYKh/dSUgVdxpeFdQYdCy+XszlErqObxZZRlhVunj8wam7JtFyZwCdP3Lkgn0ZnWB4 Eadg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=Jg75dROtWgyWOZlQ6FKCQof9SLCUskha8eUAEJwUBnY=; b=cH3MdE8ZBm6BCHxVHcfYjOTmElisq/dfPdfUDdZ7HnVX9Ib6/BR024cIxorJrQQjFO 5LswVW0oE1iA+0/6rJqifN6eWlYiMxuWT2eplnFXVkqYaaLhdxf2c7QIgu6D6M2NrprF 8jhcsy2wp10sNGvKFGK78jntGi/Lt1r7LbA3ojJghmJVdc4wG0w34MSJWe90c3Pw9uTs za9APs06SR9EorsLqBOiw02TFszkXQwcCksRpfCfEKPtW2I2VNRrB/Yg/Trd3MZ8Q7Gh yGqWH9w0Pd9317WhNVSs2ibIYjfOPoUOHTUgH7KSHP0jxhwlLlFFfNQWCHA4tAGeWDk+ nUkQ==
X-Gm-Message-State: AGi0PubFZ69ywsqt7PAOo7Vl6+aNdgPqyvvVPaygOEwoLCTPpJGBXMfY zRm/MfV3uHGAsd/nDwQAGGnD2mgXw5KWle4r68zlduo=
X-Google-Smtp-Source: APiQypIPpCW7FUPwrdketC07F5Tcmp6J2XYWK/TcXd0j6dCgD68zk9W/BxB4k2VC/xC3Lb4b16hB/+e03Na5h3Z5u78=
X-Received: by 2002:a05:620a:85d:: with SMTP id u29mr8152949qku.496.1588577807532;  Mon, 04 May 2020 00:36:47 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 May 2020 03:36:46 -0400
From: Dominick Baier 
MIME-Version: 1.0
Date: Mon, 4 May 2020 03:36:46 -0400
Message-ID: 
To: oauth@ietf.org, vittorio.bertocci@auth0.com
Content-Type: multipart/alternative; boundary="000000000000ea9d4205a4cd9715"
Archived-At: 
Subject: [OAUTH-WG] JWT profile and IdentityServer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 07:36:51 -0000

--000000000000ea9d4205a4cd9715
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey,

Just some notes on applying the JWT profile to IdentityServer

* we emit the at+jwt typ - that=E2=80=99s very useful
* we emit iat in addition to nbf (if we would remove nbf, we would break
the .NET JWT library from Microsoft - I guess that=E2=80=99s the reason AAD=
 emits
it as well)
* we have an option to emit scope as a space delimited string (we used a
string array for historic reasons - also because that=E2=80=99s how the cla=
ims
plumbing in .NET prefers it)

* aud

Audience is optional in IdentityServer if you request scopes that do not
have an association to a resource. I personally think this is the right way
to go. You can =E2=80=9Cforce=E2=80=9D an audience even for this situation =
if you
absolutely want to

* sub vs client_id

In IdentityServer access tokens that do not have a user present, do not
have a sub claim - only client_id. If there is a user present, sub ALWAYS
represents the user.

I was prototyping a setting to emit the sub claim for situation where there
is no user, which would not be hard to do - but we found out that there are
many situations where this would need VERY THOROUGH testing of all the
various flows to not introduce subtle security bugs

* the user info endpoint needs to do extra checking
* extension grants that did not use to present users
* token exchange scenarios
* enforce a collision domain for sub and client_id

This could all be sorted probably if I would have enough time right now -
but the bottom line is, that this ambiguity and special casing requires
careful re-writing and I guess this applies to any reasonably complex
system that is already out there. So I am still not sold that the =E2=80=9C=
dual
purpose=E2=80=9D claims are the best choice. YMMV.

IOW - we will not adopt the sub/client_id semantics as proposed by the
document.


My 2c / cheers
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

--000000000000ea9d4205a4cd9715
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Hey,=
=C2=A0

<=
/div>
Just some no=
tes on applying the JWT profile to IdentityServer

* we emit the at+jwt typ - that=E2=80=99s ve=
ry useful
* =
we emit iat in addition to nbf (if we would remove nbf, we would break the =
.NET JWT library from Microsoft - I guess that=E2=80=99s the reason AAD emi=
ts it as well)
* we have an option to emit scope as a space delimited string (we used a=
 string array for historic reasons - also because that=E2=80=99s how the cl=
aims plumbing in .NET prefers it)

* aud

Audience is optional in IdentityServer if you request scopes that do not =
have an association to a resource. I personally think this is the right way=
 to go. You can =E2=80=9Cforce=E2=80=9D an audience even for this situation=
 if you absolutely want to

* sub vs client_id

In IdentityServer access tokens that do not have a user present, do=
 not have a sub claim - only client_id. If there is a user present, sub ALW=
AYS represents the user.

I was prototyping a setting to emit the sub claim for situation where=
 there is no user, which would not be hard to do - but we found out that th=
ere are many situations where this would need VERY THOROUGH testing of all =
the various flows to not introduce subtle security bugs

* the user info endpoint needs to do e=
xtra checking
* extension grants that did not use to present users
* token exchange scenarios
=

* enforce a colli=
sion domain for sub and client_id

This could all be sorted probably if I would have enough tim=
e right now - but the bottom line is, that this ambiguity and special casin=
g requires careful re-writing and I guess this applies to any reasonably co=
mplex system that is already out there. So I am still not sold that the =E2=
=80=9Cdual purpose=E2=80=9D claims are the best choice. YMMV.

IOW - we will not adopt the sub/=
client_id semantics as proposed by the document.


My 2c / cheers=C2=A0
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier


--000000000000ea9d4205a4cd9715--


From nobody Mon May  4 01:20:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74773A0147 for ; Mon,  4 May 2020 01:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Dmf04MADnk for ; Mon,  4 May 2020 01:20:16 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9463A0112 for ; Mon,  4 May 2020 01:20:16 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id 145so5163513pfw.13 for ; Mon, 04 May 2020 01:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=cK9V0UG38Eb2u+jUJLw/p7tzimJVbNebAo0mVNToEXg=; b=TGbh5ZSfdhPcE1sjs/yywvvJhGpkDW355FTM3mj8vXAiamTwaOTFJ0Eu0X9m/NB7i+ V5kirxt+0xO6tr/cZmPu6NeD96sNNJS6/pjJY62RZyCu2ZOdQSBqRKdN7Cj+H4LrFhgh VQUJvcMvMwKH1awLRqo6+J/+XtMrE3FM4M83heJTH93HsNcscqu03tm0BNLRCnwHQrzM deL4TBLYmlkIcqBZw2NvLWN+qFXIXDhpTLGzxxEsdSUiu4+AURAt+AO+RNqZMWP8EDQs QLagtIw3x1edwb6Y7JlBPKVoUvG4xC+jne9fVjPDFe2eQ7RjuxPI+C9SjB9fYiQNqx9c 2brg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=cK9V0UG38Eb2u+jUJLw/p7tzimJVbNebAo0mVNToEXg=; b=bi5cwCir6KZZmjRtiS0BVW6UvTl3o/xbBAEwWmNx6jcDOaWtPXbx7lloofoRpAEWMl KYp5Bceb0zgKyD0ix9isYDc6oyKyBVht5F6oIOcCXWo6QG5txB0d4zPi2EjmPq+EhMIp 4dcqy9aXXk0pmTsA38voNbLYevKMnD23VMijX+zJwD0nD1/JkyWjlU+6V8vmmpBIpmhR V1ASWvrs8zN8lCSdpWuMhOcEhHqUtMlF42pOfIl4ydnsAvaLvvzs3L9v9+GNrCXPqTuB pAUWHexC3fglAEnTPtpk03OQAqRMRTsm3g7RAlFLWwdKK56CwK6V8dHOY8UKYjDrCS5x 34oQ==
X-Gm-Message-State: AGi0Puaoo0rpSVvm4g+9gDYfepX7ZM3DXQAXtnAa0WRRFGDVOzFoIIyl IzXvvOF9KAOQ0wo4zaZfYraRtw==
X-Google-Smtp-Source: APiQypKqzp0gXFY3HZ3/hmPvk25S+8C5ih4q02dMUWZzfhFlDOTDJVzUqai6QpdBxUhrJeeNeRa8Sw==
X-Received: by 2002:aa7:9546:: with SMTP id w6mr16445217pfq.114.1588580415549;  Mon, 04 May 2020 01:20:15 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id l64sm6553201pjb.44.2020.05.04.01.20.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2020 01:20:15 -0700 (PDT)
From: Vittorio Bertocci 
To: Dominick Baier , "oauth@ietf.org" 
Thread-Topic: JWT profile and IdentityServer
Thread-Index: AVE9N2dzbaeCGd3GrvweciKl9BMni4nJatxf
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 4 May 2020 08:20:14 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB1501DD31A0B6743C680D3382AEA60MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] JWT profile and IdentityServer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 08:20:19 -0000

--_000_MWHPR19MB1501DD31A0B6743C680D3382AEA60MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thank you Dominick, very useful!
I=92d like to understand more about the security risks you mention. My goal=
 is not to change your mind on the implementatio, just to make sure I bette=
r understand the general implication.
>* the user info endpoint needs to do extra checking
This is an interesting use case. Often the token issued for the userinfo is=
 formatless, given that it is colocated within the AS, but I can see how us=
ing JWT for your own userinfo might be useful if you don=92t particularly c=
are about token size or you don=92t want to handle an internal token format=
/reference.
Could you expand on the security risk? Either the sub doesn=92t correspond =
to a user, or if it does, the AS itself was the issuer hence it had full co=
ntrol of whether a sub for a user would end up in a token obtained via clie=
nt creds grant=85 the main way I can see this going south would be if the d=
eveloper is allowed to place an arbitrary sub value, but in that case the i=
ssue seem larger (eg in a grant including a user, placing the sub of anothe=
r user).

>* extension grants that did not use to present users
Technically we are still not presenting users- the sub is the authenticated=
 subject, which can be a user or an app. Here I am channeling the consensus=
 that was reached after quite a few back and forths, see https://mailarchiv=
e.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.
But besides the nitpicking. Could you expand on the extension grants you ar=
e thinking of, and how they=92d be affected?
>* token exchange scenarios
This is another really interesting point. I admit I haven=92t studied the R=
FC and I might be remembering an older version, but I believe the specs ref=
erred to principals, which aren=92t necessarily human; and I remember one d=
ev from the community describing a scenario where he would have liked to be=
 able to do OBO with machine identities, and his scenario was reasonable.
Is there anything specific that breaks in your implementation of token exch=
ange if you have a sub not corresponding to a user?

>* enforce a collision domain for sub and client_id
If your product allows developers to arbitrarily set values for one or both=
 of those, I totally see how enforcement would be extra work! I would argue=
 that in that case perhaps you don=92t have to, if the user can set arbitra=
ry values they can already do things that would break standards (like assig=
ning the same sub to two different users) hence in that case you can=92t be=
 responsible for it at product design, it=92s kind of up to them.

Note, I know that answering the above might require extra work in investiga=
ting and writing about it, I don=92t mean to burden you with it. My aim her=
e is understanding whether the challenges you identified mostly stem from t=
he underlying assumption =93presence of a sub=3D>it=92s a user=94, which is=
 understandable but was established in the discussions referenced above not=
 to be enough to violate 7519, or if there are other factors at play that i=
ntroduce challenges when sub is used that way.
Thanks again for putting time in checking this and considering implementing=
 it!
Cheers,
V.

From: Dominick Baier 
Date: Monday, May 4, 2020 at 00:36
To: "oauth@ietf.org" , "vittorio.bertocci@auth0.com" 
Subject: JWT profile and IdentityServer

Hey,

Just some notes on applying the JWT profile to IdentityServer

* we emit the at+jwt typ - that=92s very useful
* we emit iat in addition to nbf (if we would remove nbf, we would break th=
e .NET JWT library from Microsoft - I guess that=92s the reason AAD emits i=
t as well)
* we have an option to emit scope as a space delimited string (we used a st=
ring array for historic reasons - also because that=92s how the claims plum=
bing in .NET prefers it)

* aud

Audience is optional in IdentityServer if you request scopes that do not ha=
ve an association to a resource. I personally think this is the right way t=
o go. You can =93force=94 an audience even for this situation if you absolu=
tely want to

* sub vs client_id

In IdentityServer access tokens that do not have a user present, do not hav=
e a sub claim - only client_id. If there is a user present, sub ALWAYS repr=
esents the user.

I was prototyping a setting to emit the sub claim for situation where there=
 is no user, which would not be hard to do - but we found out that there ar=
e many situations where this would need VERY THOROUGH testing of all the va=
rious flows to not introduce subtle security bugs

* the user info endpoint needs to do extra checking
* extension grants that did not use to present users
* token exchange scenarios
* enforce a collision domain for sub and client_id

This could all be sorted probably if I would have enough time right now - b=
ut the bottom line is, that this ambiguity and special casing requires care=
ful re-writing and I guess this applies to any reasonably complex system th=
at is already out there. So I am still not sold that the =93dual purpose=94=
 claims are the best choice. YMMV.

IOW - we will not adopt the sub/client_id semantics as proposed by the docu=
ment.


My 2c / cheers
=97=97=97
Dominick Baier

--_000_MWHPR19MB1501DD31A0B6743C680D3382AEA60MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Thank you Dominick, very useful!


I=92d like to understand more about the security ris=
ks you mention. My goal is not to change your mind on the implementatio, ju=
st to make sure I better understand the general implication.




>* the user info endpoint needs to do extra checking


This is an interesting use case. Often the token issued for the userinfo=
 is formatless, given that it is colocated within the AS, but I can see how=
 using JWT for your own userinfo might
 be useful if you don=92t particularly care about token size or you don=92t=
 want to handle an internal token format/reference.


Could you expand on the security risk? Either the sub doesn=92t correspo=
nd to a user, or if it does, the AS itself was the issuer hence it had full=
 control of whether a sub for a user would
 end up in a token obtained via client creds grant=85 the main way I can se=
e this going south would be if the developer is allowed to place an arbitra=
ry sub value, but in that case the issue seem larger (eg in a grant includi=
ng a user, placing the sub of another
 user).  




>* extension grants that did not use to present users<=
/span>


Technically we are still not presenting users- the sub is the authentica=
ted subject, which can be a user or an app. Here I am channeling the consen=
sus that was reached after quite a few
 back and forths, see https://m=
ailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.=



But besides the nitpicking. Could you expand on the =
extension grants you are thinking of, and how they=92d be affected?




>* token exchange scenarios


This is another really interesting point. I admit I haven=92t studied th=
e RFC and I might be remembering an older version, but I believe the specs =
referred to principals, which aren=92t necessarily
 human; and I remember one dev from the community describing a scenario whe=
re he would have liked to be able to do OBO with machine identities, and hi=
s scenario was reasonable.


Is there anything specific that breaks in your implementation of token e=
xchange if you have a sub not corresponding to a user?

 


>* enforce a collision domain for sub and client_id=



If your product allows developers to arbitrarily set=
 values for one or both of those, I totally see how enforcement would be ex=
tra work! I would argue that in that case perhaps you don=92t have to, if t=
he user can set arbitrary values they
 can already do things that would break standards (like assigning the same =
sub to two different users) hence in that case you can=92t be responsible f=
or it at product design, it=92s kind of up to them.


 


Note, I know that answering the above might require =
extra work in investigating and writing about it, I don=92t mean to burden =
you with it. My aim here is understanding whether the challenges you identi=
fied mostly stem from the underlying
 assumption =93presence of a sub=3D>it=92s a user=94, which is understan=
dable but was established in the discussions referenced above not to be eno=
ugh to violate 7519, or if there are other factors at play that introduce c=
hallenges when sub is used that way.


Thanks again for putting time in checking this and c=
onsidering implementing it!


Cheers,


V. 


 




From=
: Dominick Baier &l=
t;dbaier@leastprivilege.com>

Date: Monday, May 4, 2020 at 00:36

To: "oauth@ietf.org" <oauth@ietf.org>, "vittori=
o.bertocci@auth0.com" <vittorio.bertocci@auth0.com>

Subject: JWT profile and IdentityServer






 






Hey, 






 






Just some notes on applying the JWT profile to IdentityServer=







 






* we emit the at+jwt typ - that=92s very useful





* we emit iat in addition to nbf (if we would remove nbf, we would break=
 the .NET JWT library from Microsoft - I guess that=92s the reason AAD emit=
s it as well)






* we have an option to emit scope as a space delimited string (we used a=
 string array for historic reasons - also because that=92s how the claims p=
lumbing in .NET prefers it)






 






* aud






 






Audience is optional in IdentityServer if you request scopes that do not=
 have an association to a resource. I personally think this is the right wa=
y to go. You can =93force=94 an audience
 even for this situation if you absolutely want to






 






* sub vs client_id






 






In IdentityServer access tokens that do not have a user present, do not =
have a sub claim - only client_id. If there is a user present, sub ALWAYS r=
epresents the user.






 






I was prototyping a setting to emit the sub claim for situation where th=
ere is no user, which would not be hard to do - but we found out that there=
 are many situations where this would
 need VERY THOROUGH testing of all the various flows to not introduce subtl=
e security bugs






 






* the user info endpoint needs to do extra checking





* extension grants that did not use to present users





* token exchange scenarios






* enforce a collision domain for sub and client_id






 






This could all be sorted probably if I would have enough time right now =
- but the bottom line is, that this ambiguity and special casing requires c=
areful re-writing and I guess this applies
 to any reasonably complex system that is already out there. So I am still =
not sold that the =93dual purpose=94 claims are the best choice. YMMV.=







 






IOW - we will not adopt the sub/client_id semantics as proposed by the d=
ocument.






 






 




My 2c / cheers 




=97=97=97 




Dominick Baier










--_000_MWHPR19MB1501DD31A0B6743C680D3382AEA60MWHPR19MB1501namp_--


From nobody Mon May  4 01:55:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0CA3A0408 for ; Mon,  4 May 2020 01:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svVer1CkZNLU for ; Mon,  4 May 2020 01:55:44 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0BD3A0406 for ; Mon,  4 May 2020 01:55:44 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id c10so4762657qka.4 for ; Mon, 04 May 2020 01:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=l1pTwey+NioQB5WRoQ5/YmAIjOU3Cijfr3iimJLEfTU=; b=WhC2LinO4qL29k/BG57NGMBAB+QBo+G87vKlm0X2EcyEjQQ+MpwJc4kyKZXQSq232i 22zYOHyaUU/oK3ASvhPX3Dh+XMi+7JgXVjJXiuhbP2aY9KaLX5nQhq6Q3t6zHU0ooC0W jAOqUo9Xa1PKoyUrjU2QI/DOTm8QaVjvI6XWnVyOFzxX2KCU2j0pXkQVGWD6/DANHnOx 2FhdhDi7DQmW3rby8NMGM/VxBFnWT9I4O0cg77llMZ3EYLzrz7zhZeZopHSbSxL3yPyx wapaM3VGv4cmmrBsaxpofJVQzK8fbac7N+6AuQ78NiDWFgXrIXnl/fOkklQO/WR+K0tL +ymQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=l1pTwey+NioQB5WRoQ5/YmAIjOU3Cijfr3iimJLEfTU=; b=Zb0LlBXdryAiVaud7U/8Vs3MUOnKcbSyakTth9aUpTnv69WLVOLqUF4GnPaXKlQCBL 9SKtHcAgEAlYbTm6L6ipQth2pbe43vE3710YSoxXtyedISY6vZpsgvO+bm6l8WMvwr6Y 4VwLy80ju6OZ+fKCMH8rk2FcQTqokd6zsp8V16GaoGJOaRAI0+BkalIJeGVmOadf9POC dewzyInn4TyqPnungV44Q0ypDUYCZJ2ICDyFoyhXMlLLX2q0FotCtLof0c36x7/BuMkW huGkBHhHAEv5JqLbmwQy6BXzZaKEyxOZMbF3pDMnFrY1ClZG1MSh8CtVZ7YNDO6bNN/8 IQiA==
X-Gm-Message-State: AGi0PuZY6kLIB596R9LEy/OjitF/DaDHj0Gjlhf1P3EY9lXn8oq5R5tB TMOif4ssRryoy6Z1dPrMVLrqhWoNcT+sIRU0/U/uh4Y=
X-Google-Smtp-Source: APiQypK7DGJLNlACvYuBm98KfMHFoydXtYuj/rozSv2Q8uuar6VEwHYEkbtk+GW99rsId/ZmMy2cR+99pcSDmaT6GII=
X-Received: by 2002:a37:82c1:: with SMTP id e184mr15674080qkd.186.1588582542574;  Mon, 04 May 2020 01:55:42 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 May 2020 04:55:41 -0400
From: Dominick Baier 
In-Reply-To: 
References:  
MIME-Version: 1.0
Date: Mon, 4 May 2020 04:55:41 -0400
Message-ID: 
To: "oauth@ietf.org" , Vittorio Bertocci 
Content-Type: multipart/alternative; boundary="0000000000002599dc05a4ceb2f2"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT profile and IdentityServer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 08:55:47 -0000

--0000000000002599dc05a4ceb2f2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey,

No problem - this email was not intended to make you change the document.
Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a =E2=80=9Coff the shelf=E2=80=9D product or SaaS -=
 it is a
framework. IOW - developers have much greater flexibility and less
constraints to implement custom scenarios. This - as a consequence - allows
doing something =E2=80=9Cdangerous=E2=80=9D - e.g.we cannot enforce how sub=
s or client_id
are generated.

* Every token/identity handling logic in IdentityServer is based on a
simple rule: =E2=80=9Cif there is a sub - a user is involved, if not - then=
 not=E2=80=9D.
Call me old-school - but simplicity wins ;) And this formula has worked
very well for us and our customers. Changing this means we need to re-visit
every place where this logic is applied - so do our customers in both their
STS and resource server implementations. This change is of course doable -
but def. not at this moment in time especially since I am still struggling
if this is the right thing to do or not.

Lastly - I am not sure I understand this comment "not to be enough to
violate 7519=E2=80=9D.

The sub claim is OPTIONAL.

https://tools.ietf.org/html/rfc7519#section-4.1.2

And so is aud btw.

So I do not really need to comment on the below scenarios in detail because
they are all a consequence of the above. I could make all these changes,
but they might require a substantial internal change of our logic. So we
decided to not do it. I can only imagine that other STS implementations
come to the same conclusion. And yes I know - you cannot please everybody ;=
)


Still some comment inline...


thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci (vittorio.bertocci@auth0.com)
wrote:

Thank you Dominick, very useful!

I=E2=80=99d like to understand more about the security risks you mention. M=
y goal
is not to change your mind on the implementatio, just to make sure I better
understand the general implication.

*>* the user info endpoint needs to do extra checking*

This is an interesting use case. Often the token issued for the userinfo is
formatless, given that it is colocated within the AS, but I can see how
using JWT for your own userinfo might be useful if you don=E2=80=99t partic=
ularly
care about token size or you don=E2=80=99t want to handle an internal token
format/reference.


Could you expand on the security risk? Either the sub doesn=E2=80=99t corre=
spond to
a user, or if it does, the AS itself was the issuer hence it had full
control of whether a sub for a user would end up in a token obtained via
client creds grant=E2=80=A6 the main way I can see this going south would b=
e if the
developer is allowed to place an arbitrary sub value, but in that case the
issue seem larger (eg in a grant including a user, placing the sub of
another user).


We use the JWT. Sub =3D user ID. OIDC scopes =3D what data is returned. Thi=
s
needs slightly updated logic



*>* extension grants that did not use to present users*

Technically we are still not presenting users- the sub is the authenticated
subject, which can be a user or an app. Here I am channeling the consensus
that was reached after quite a few back and forths, see
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.

That=E2=80=99s fine - not trying to change your mind



But besides the nitpicking. Could you expand on the extension grants you
are thinking of, and how they=E2=80=99d be affected?

Again our internal extension grant logic is based on the existence of the
sub claim after the response data has been generated. If sub is present we
invoke a whole pipeline around user centric claims. Needs to be changed.



*>* token exchange scenarios*

This is another really interesting point. I admit I haven=E2=80=99t studied=
 the RFC
and I might be remembering an older version, but I believe the specs
referred to principals, which aren=E2=80=99t necessarily human; and I remem=
ber one
dev from the community describing a scenario where he would have liked to
be able to do OBO with machine identities, and his scenario was reasonable.

Is there anything specific that breaks in your implementation of token
exchange if you have a sub not corresponding to a user?

See above.





>* enforce a collision domain for sub and client_id

If your product allows developers to arbitrarily set values for one or both
of those, I totally see how enforcement would be extra work! I would argue
that in that case perhaps you don=E2=80=99t have to, if the user can set ar=
bitrary
values they can already do things that would break standards (like
assigning the same sub to two different users) hence in that case you can=
=E2=80=99t
be responsible for it at product design, it=E2=80=99s kind of up to them.



Note, I know that answering the above might require extra work in
investigating and writing about it, I don=E2=80=99t mean to burden you with=
 it. My
aim here is understanding whether the challenges you identified mostly stem
from the underlying assumption =E2=80=9Cpresence of a sub=3D>it=E2=80=99s a=
 user=E2=80=9D, which is
understandable but was established in the discussions referenced above not
to be enough to violate 7519, or if there are other factors at play that
introduce challenges when sub is used that way.

Thanks again for putting time in checking this and considering implementing
it!

Cheers,

V.



*From: *Dominick Baier 
*Date: *Monday, May 4, 2020 at 00:36
*To: *"oauth@ietf.org" , "vittorio.bertocci@auth0.com" <
vittorio.bertocci@auth0.com>
*Subject: *JWT profile and IdentityServer



Hey,



Just some notes on applying the JWT profile to IdentityServer



* we emit the at+jwt typ - that=E2=80=99s very useful

* we emit iat in addition to nbf (if we would remove nbf, we would break
the .NET JWT library from Microsoft - I guess that=E2=80=99s the reason AAD=
 emits
it as well)

* we have an option to emit scope as a space delimited string (we used a
string array for historic reasons - also because that=E2=80=99s how the cla=
ims
plumbing in .NET prefers it)



* aud



Audience is optional in IdentityServer if you request scopes that do not
have an association to a resource. I personally think this is the right way
to go. You can =E2=80=9Cforce=E2=80=9D an audience even for this situation =
if you
absolutely want to



* sub vs client_id



In IdentityServer access tokens that do not have a user present, do not
have a sub claim - only client_id. If there is a user present, sub ALWAYS
represents the user.



I was prototyping a setting to emit the sub claim for situation where there
is no user, which would not be hard to do - but we found out that there are
many situations where this would need VERY THOROUGH testing of all the
various flows to not introduce subtle security bugs



* the user info endpoint needs to do extra checking

* extension grants that did not use to present users

* token exchange scenarios

* enforce a collision domain for sub and client_id



This could all be sorted probably if I would have enough time right now -
but the bottom line is, that this ambiguity and special casing requires
careful re-writing and I guess this applies to any reasonably complex
system that is already out there. So I am still not sold that the =E2=80=9C=
dual
purpose=E2=80=9D claims are the best choice. YMMV.



IOW - we will not adopt the sub/client_id semantics as proposed by the
document.





My 2c / cheers

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

--0000000000002599dc05a4ceb2f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Hey,=
=C2=A0

<=
/div>
No problem -=
 this email was not intended to make you change the document. Just my concl=
usions.

=

OK - let me=
 just set the scene first

* IdentityServer is not a =E2=80=9Coff the shelf=E2=80=9D product or=
 SaaS - it is a framework. IOW - developers have much greater flexibility a=
nd less constraints to implement custom scenarios. This - as a consequence =
- allows doing something =E2=80=9Cdangerous=E2=80=9D - e.g.we cannot enforc=
e how subs or client_id are generated.

* Every token/identity handling logic in IdentityServer=
 is based on a simple rule: =E2=80=9Cif there is a sub - a user is involved=
, if not - then not=E2=80=9D. Call me old-school - but simplicity wins ;) A=
nd this formula has worked very well for us and our customers. Changing thi=
s means we need to re-visit every place where this logic is applied - so do=
 our customers in both their STS and resource server implementations. This =
change is of course doable - but def. not at this moment in time especially=
 since I am still struggling if this is the right thing to do or not.
=


Lastly - I am not sure I=
 understand this comment "not to be enough to violate 7519=E2=80=9D.

The sub claim is OPT=
IONAL.

<=
/div>

And so is aud btw.

So I do not really need to comment on the below scenarios in deta=
il because they are all a consequence of the above. I could make all these =
changes, but they might require a substantial internal change of our logic.=
 So we decided to not do it. I can only imagine that other STS implementati=
ons come to the same conclusion. And yes I know - you cannot please everybo=
dy ;)


Still some comment i=
nline...

=

thanks
 =E2=80=94=E2=80=94=E2=80=94
Dominick Baier
 
On 4. May 2020 at 10:20:16, Vittorio=
 Bertocci (vittorio.bertocci=
@auth0.com) wrote:
 
Thank you Dominick, very useful!
I=E2=80=
=99d like to understand more about the security risks you mention. My goal =
is not to change your mind on the implementatio, just to make sure I better=
 understand the general implication.
>=
* the user info endpoint needs to do extra checking
This is=
 an interesting use case. Often the token issued for the userinfo is format=
less, given that it is colocated within the AS, but I can see how using JWT=
 for your own userinfo might be useful if you don=E2=80=99t particularly ca=
re about token size or you don=E2=80=99t want to handle an internal token f=
ormat/reference.

Could you e=
xpand on the security risk? Either the sub doesn=E2=80=99t correspond to a =
user, or if it does, the AS itself was the issuer hence it had full control=
 of whether a sub for a user would end up in a token obtained via client cr=
eds grant=E2=80=A6 the main way I can see this going south would be if the =
developer is allowed to place an arbitrary sub value, but in that case the =
issue seem larger (eg in a grant including a user, placing the sub of anoth=
er user). =C2=A0
<=
br>
We use the JWT. Sub =3D user ID. OIDC scopes =3D what data is ret=
urned. This needs slightly updated logic


>* extension grants that did not=
 use to present users
Technically we are still not presentin=
g users- the sub is the authenticated subject, which can be a user or an ap=
p. Here I am channeling the consensus that was reached after quite a few ba=
ck and forths, see=C2=A0https://mailarchive.ietf.org/arch/msg=
/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.
That=E2=80=99s fine - not trying to change your mind=



But besides the nitpicking. Could you expand on the=
 extension grants you are thinking of, and how they=E2=80=99d be affected?<=
/p>
Again our internal extens=
ion grant logic is based on the existence of the sub claim after the respon=
se data has been generated. If sub is present we invoke a whole pipeline ar=
ound user centric claims. Needs to be changed.


>* token exchange sce=
narios
This is another really interesting point. I admit I h=
aven=E2=80=99t studied the RFC and I might be remembering an older version,=
 but I believe the specs referred to principals, which aren=E2=80=99t neces=
sarily human; and I remember one dev from the community describing a scenar=
io where he would have liked to be able to do OBO with machine identities, =
and his scenario was reasonable.
Is there anything specific that=
 breaks in your implementation of token exchange if you have a sub not corr=
esponding to a user?
=

See above.


=C2=A0
>* enforce a collision domain for sub and =
client_id
If your product allows developer=
s to arbitrarily set values for one or both of those, I totally see how enf=
orcement would be extra work! I would argue that in that case perhaps you d=
on=E2=80=99t have to, if the user can set arbitrary values they can already=
 do things that would break standards (like assigning the same sub to two d=
ifferent users) hence in that case you can=E2=80=99t be responsible for it =
at product design, it=E2=80=99s kind of up to them.
=C2=A0
Note, I know that answering the above m=
ight require extra work in investigating and writing about it, I don=E2=80=
=99t mean to burden you with it. My aim here is understanding whether the c=
hallenges you identified mostly stem from the underlying assumption =E2=80=
=9Cpresence of a sub=3D>it=E2=80=99s a user=E2=80=9D, which is understan=
dable but was established in the discussions referenced above not to be eno=
ugh to violate 7519, or if there are other factors at play that introduce c=
hallenges when sub is used that way.
Thanks again=
 for putting time in checking this and considering implementing it!
Cheers,
V.=C2=A0
=C2=A0
From:=
=C2=A0Dominick=
 Baier <dbaier@leastprivile=
ge.com>
Date:=C2=A0Monday, May 4, 2020 at 00:36
To:=C2=A0"oauth@ietf.=
org" <oauth@ietf.org>,=
 "vittorio.bertocci@aut=
h0.com" <vittori=
o.bertocci@auth0.com>
Subject:=C2=A0JWT profile and IdentityServer
=

=C2=A0
Hey,=C2=A0
=C2=A0
Just some notes on applying the JWT profile=
 to IdentityServer
=C2=A0
* we=
 emit the at+jwt typ - that=E2=80=99s very useful
* w=
e emit iat in addition to nbf (if we would remove nbf, we would break the .=
NET JWT library from Microsoft - I guess that=E2=80=99s the reason AAD emit=
s it as well)
* we have an option to emit scope as a =
space delimited string (we used a string array for historic reasons - also =
because that=E2=80=99s how the claims plumbing in .NET prefers it)
=C2=A0
* aud
=C2=
=A0
Audience is optional in IdentityServer if you req=
uest scopes that do not have an association to a resource. I personally thi=
nk this is the right way to go. You can =E2=80=9Cforce=E2=80=9D an audience=
 even for this situation if you absolutely want to
=
=C2=A0
* sub vs client_id
=C2=
=A0
In IdentityServer access tokens that do not have =
a user present, do not have a sub claim - only client_id. If there is a use=
r present, sub ALWAYS represents the user.
=C2=A0
I was prototyping a setting to emit the sub claim for si=
tuation where there is no user, which would not be hard to do - but we foun=
d out that there are many situations where this would need VERY THOROUGH te=
sting of all the various flows to not introduce subtle security bugs=

=C2=A0
* the user info endpoint needs=
 to do extra checking
* extension grants that did not=
 use to present users
* token exchange scenarios
* enforce a collision domain for sub and client_id=

=C2=A0
This could all be sorted proba=
bly if I would have enough time right now - but the bottom line is, that th=
is ambiguity and special casing requires careful re-writing and I guess thi=
s applies to any reasonably complex system that is already out there. So I =
am still not sold that the =E2=80=9Cdual purpose=E2=80=9D claims are the be=
st choice. YMMV.
=C2=A0
IOW - w=
e will not adopt the sub/client_id semantics as proposed by the document.
=C2=A0
=C2=A0
My 2c / cheers=C2=A0
=
=E2=80=94=E2=80=94=E2=80=94=C2=A0
Dominick Baier


--0000000000002599dc05a4ceb2f2--


From nobody Mon May  4 02:00:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DC33A040A for ; Mon,  4 May 2020 02:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JmH517euY5t for ; Mon,  4 May 2020 02:00:35 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682BB3A0408 for ; Mon,  4 May 2020 02:00:35 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id t3so15835543qkg.1 for ; Mon, 04 May 2020 02:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=lBWKRScnUf3FVqnlj/7Hr3sB0dVjnViJcXgGYwfqVRc=; b=jF5LjwmDIaZeO+dhCBvgT5DCt36C8noHAeYQUHRSvMMCPt8ec2dcaxJaYQ1TR8rQ76 0HDSSbSH2xpx3CDCg7t56UAikiCg/cqrRjC2ZWasn9ot0M2+W9UPtIR0b/7SnSXc9hlL 5nA5skiT2Z37Fed7vHn4cRecOmonfqSVywOVnTgOdznPBbA4I1ANvhYEYTmLo/1+i/sZ zI/7FP7QfubSVqkNhtYEL9juwJtR6DEot6acUNE0ivNbEBSaYEwPkfw+MxGr8o0HHIb9 xWqaA7jvoGMoDPGUcNaILpxGbe4WoKr8P3qtVVzcCpWo7tm/rYZk72UrWt152IoK/UJ0 jHPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=lBWKRScnUf3FVqnlj/7Hr3sB0dVjnViJcXgGYwfqVRc=; b=bjabhlyLHSYJfriK87DQsSd72fE9DlG/3IiBl9eNWbjVkEt+ZL9uqGjt5doUQIClZY O9+qXgaCZBAd3rEAoiOsMNIo4BC6TD2XemKGzsePmItCARydISZltjPkrA8q7ZX63zkN HteUL5LNuh1L5ZgY/a1NfQHPECZS9FRkcasp2pc+M5/sDReBuQg/O96t/y0zRS65BBhC /wq0OPhO6GKH/nQgRMQHluSJr3glNLti4PmFxIzh6A+V6iJEpEjeAj2VYS9t4cafbwHC eQ9ZCZEHVTNundbFFYN7cBHoMWicKYcxMhHiLBNPkgrqkJSKeJTylfYIC8MDYM/JhXQj qOMQ==
X-Gm-Message-State: AGi0PuY2b6Of7iXbmMG2gH2Z0VuC4X21mbRpEp21wDLUNV7u0rRBBgew 57UYoedSKXdFsnmiUqlCihrSNznSz+ozrzo28WIcWSg=
X-Google-Smtp-Source: APiQypLxW8mb6q6ClRpy48bFvlyvbxcFSwB2OX9rUwTKTlCqkdgyYlHe+8y8zGJP91IpPnmLHJ/h8NSlwThUCBD+znw=
X-Received: by 2002:a37:4b4f:: with SMTP id y76mr14792234qka.292.1588582834205;  Mon, 04 May 2020 02:00:34 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 May 2020 05:00:33 -0400
From: Dominick Baier 
In-Reply-To: 
References:   
MIME-Version: 1.0
Date: Mon, 4 May 2020 05:00:33 -0400
Message-ID: 
To: Vittorio Bertocci , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000087c90705a4cec355"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT profile and IdentityServer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 09:00:38 -0000

--00000000000087c90705a4cec355
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Oh - and last thing I forgot to mention.

We had the luxury of designing IdentityServer from the ground up after OIDC
has been released. So it really was fine tuned to be a OIDC + OAuth
implementation. Hence the strong semantics of the sub claim for both the
OIDC and OAuth parts. We think this is right because all of our customers
use both in conjunction.

IOW - you move our cheese ;) But don=E2=80=99t worry about it.

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 4. May 2020 at 10:55:41, Dominick Baier (dbaier@leastprivilege.com)
wrote:

Hey,

No problem - this email was not intended to make you change the document.
Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a =E2=80=9Coff the shelf=E2=80=9D product or SaaS -=
 it is a
framework. IOW - developers have much greater flexibility and less
constraints to implement custom scenarios. This - as a consequence - allows
doing something =E2=80=9Cdangerous=E2=80=9D - e.g.we cannot enforce how sub=
s or client_id
are generated.

* Every token/identity handling logic in IdentityServer is based on a
simple rule: =E2=80=9Cif there is a sub - a user is involved, if not - then=
 not=E2=80=9D.
Call me old-school - but simplicity wins ;) And this formula has worked
very well for us and our customers. Changing this means we need to re-visit
every place where this logic is applied - so do our customers in both their
STS and resource server implementations. This change is of course doable -
but def. not at this moment in time especially since I am still struggling
if this is the right thing to do or not.

Lastly - I am not sure I understand this comment "not to be enough to
violate 7519=E2=80=9D.

The sub claim is OPTIONAL.

https://tools.ietf.org/html/rfc7519#section-4.1.2

And so is aud btw.

So I do not really need to comment on the below scenarios in detail because
they are all a consequence of the above. I could make all these changes,
but they might require a substantial internal change of our logic. So we
decided to not do it. I can only imagine that other STS implementations
come to the same conclusion. And yes I know - you cannot please everybody ;=
)


Still some comment inline...


thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci (vittorio.bertocci@auth0.com)
wrote:

Thank you Dominick, very useful!

I=E2=80=99d like to understand more about the security risks you mention. M=
y goal
is not to change your mind on the implementatio, just to make sure I better
understand the general implication.

*>* the user info endpoint needs to do extra checking*

This is an interesting use case. Often the token issued for the userinfo is
formatless, given that it is colocated within the AS, but I can see how
using JWT for your own userinfo might be useful if you don=E2=80=99t partic=
ularly
care about token size or you don=E2=80=99t want to handle an internal token
format/reference.


Could you expand on the security risk? Either the sub doesn=E2=80=99t corre=
spond to
a user, or if it does, the AS itself was the issuer hence it had full
control of whether a sub for a user would end up in a token obtained via
client creds grant=E2=80=A6 the main way I can see this going south would b=
e if the
developer is allowed to place an arbitrary sub value, but in that case the
issue seem larger (eg in a grant including a user, placing the sub of
another user).


We use the JWT. Sub =3D user ID. OIDC scopes =3D what data is returned. Thi=
s
needs slightly updated logic



*>* extension grants that did not use to present users*

Technically we are still not presenting users- the sub is the authenticated
subject, which can be a user or an app. Here I am channeling the consensus
that was reached after quite a few back and forths, see
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.

That=E2=80=99s fine - not trying to change your mind



But besides the nitpicking. Could you expand on the extension grants you
are thinking of, and how they=E2=80=99d be affected?

Again our internal extension grant logic is based on the existence of the
sub claim after the response data has been generated. If sub is present we
invoke a whole pipeline around user centric claims. Needs to be changed.



*>* token exchange scenarios*

This is another really interesting point. I admit I haven=E2=80=99t studied=
 the RFC
and I might be remembering an older version, but I believe the specs
referred to principals, which aren=E2=80=99t necessarily human; and I remem=
ber one
dev from the community describing a scenario where he would have liked to
be able to do OBO with machine identities, and his scenario was reasonable.

Is there anything specific that breaks in your implementation of token
exchange if you have a sub not corresponding to a user?

See above.





>* enforce a collision domain for sub and client_id

If your product allows developers to arbitrarily set values for one or both
of those, I totally see how enforcement would be extra work! I would argue
that in that case perhaps you don=E2=80=99t have to, if the user can set ar=
bitrary
values they can already do things that would break standards (like
assigning the same sub to two different users) hence in that case you can=
=E2=80=99t
be responsible for it at product design, it=E2=80=99s kind of up to them.



Note, I know that answering the above might require extra work in
investigating and writing about it, I don=E2=80=99t mean to burden you with=
 it. My
aim here is understanding whether the challenges you identified mostly stem
from the underlying assumption =E2=80=9Cpresence of a sub=3D>it=E2=80=99s a=
 user=E2=80=9D, which is
understandable but was established in the discussions referenced above not
to be enough to violate 7519, or if there are other factors at play that
introduce challenges when sub is used that way.

Thanks again for putting time in checking this and considering implementing
it!

Cheers,

V.



*From: *Dominick Baier 
*Date: *Monday, May 4, 2020 at 00:36
*To: *"oauth@ietf.org" , "vittorio.bertocci@auth0.com" <
vittorio.bertocci@auth0.com>
*Subject: *JWT profile and IdentityServer



Hey,



Just some notes on applying the JWT profile to IdentityServer



* we emit the at+jwt typ - that=E2=80=99s very useful

* we emit iat in addition to nbf (if we would remove nbf, we would break
the .NET JWT library from Microsoft - I guess that=E2=80=99s the reason AAD=
 emits
it as well)

* we have an option to emit scope as a space delimited string (we used a
string array for historic reasons - also because that=E2=80=99s how the cla=
ims
plumbing in .NET prefers it)



* aud



Audience is optional in IdentityServer if you request scopes that do not
have an association to a resource. I personally think this is the right way
to go. You can =E2=80=9Cforce=E2=80=9D an audience even for this situation =
if you
absolutely want to



* sub vs client_id



In IdentityServer access tokens that do not have a user present, do not
have a sub claim - only client_id. If there is a user present, sub ALWAYS
represents the user.



I was prototyping a setting to emit the sub claim for situation where there
is no user, which would not be hard to do - but we found out that there are
many situations where this would need VERY THOROUGH testing of all the
various flows to not introduce subtle security bugs



* the user info endpoint needs to do extra checking

* extension grants that did not use to present users

* token exchange scenarios

* enforce a collision domain for sub and client_id



This could all be sorted probably if I would have enough time right now -
but the bottom line is, that this ambiguity and special casing requires
careful re-writing and I guess this applies to any reasonably complex
system that is already out there. So I am still not sold that the =E2=80=9C=
dual
purpose=E2=80=9D claims are the best choice. YMMV.



IOW - we will not adopt the sub/client_id semantics as proposed by the
document.





My 2c / cheers

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

--00000000000087c90705a4cec355
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Oh -=
 and last thing I forgot to mention.

We had the luxury of designing IdentityServer from the gr=
ound up after OIDC has been released. So it really was fine tuned to be a O=
IDC + OAuth implementation. Hence the strong semantics of the sub claim for=
 both the OIDC and OAuth parts. We think this is right because all of our c=
ustomers use both in conjunction.

IOW - you move our cheese ;) But don=E2=80=99t worry about i=
t.
 
 
=E2=80=94=E2=80=94=E2=80=94Dominick Baier
 
On 4. May 2020 at =
10:55:41, Dominick Baier (dbai=
er@leastprivilege.com) wrote:
 
Hey,=C2=A0

No problem - this email was not intended to make you change the d=
ocument. Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a =E2=80=9Coff the she=
lf=E2=80=9D product or SaaS - it is a framework. IOW - developers have much=
 greater flexibility and less constraints to implement custom scenarios. Th=
is - as a consequence - allows doing something =E2=80=9Cdangerous=E2=80=9D =
- e.g.we cannot enforce how subs or client_id are generated.

* Every token/identity handling l=
ogic in IdentityServer is based on a simple rule: =E2=80=9Cif there is a su=
b - a user is involved, if not - then not=E2=80=9D. Call me old-school - bu=
t simplicity wins ;) And this formula has worked very well for us and our c=
ustomers. Changing this means we need to re-visit every place where this lo=
gic is applied - so do our customers in both their STS and resource server =
implementations. This change is of course doable - but def. not at this mom=
ent in time especially since I am still struggling if this is the right thi=
ng to do or not.

La=
stly - I am not sure I understand this comment "not to be enough to vi=
olate 7519=E2=80=9D.

The sub claim is OPTIONAL.


And so is aud btw.

So I do not really need to comment on the b=
elow scenarios in detail because they are all a consequence of the above. I=
 could make all these changes, but they might require a substantial interna=
l change of our logic. So we decided to not do it. I can only imagine that =
other STS implementations come to the same conclusion. And yes I know - you=
 cannot please everybody ;)


Still some comment inline...


thanks
 
=E2=80=94=E2=80=94=E2=80=
=94
Dominick Baier
 
On 4. May 20=
20 at 10:20:16, Vittorio Bertocci (vittorio.bertocci@auth0.com) wrote:
 
Thank you Dominick, very useful!
I=E2=80=99d like to understand more about the security risks=
 you mention. My goal is not to change your mind on the implementatio, just=
 to make sure I better understand the general implication.
>* the user info endpoint needs to do extra checking
This is an interesting use case. Often the token issued for t=
he userinfo is formatless, given that it is colocated within the AS, but I =
can see how using JWT for your own userinfo might be useful if you don=E2=
=80=99t particularly care about token size or you don=E2=80=99t want to han=
dle an internal token format/reference.
=


Could you expand on the security risk? Either the sub doesn=E2=
=80=99t correspond to a user, or if it does, the AS itself was the issuer h=
ence it had full control of whether a sub for a user would end up in a toke=
n obtained via client creds grant=E2=80=A6 the main way I can see this goin=
g south would be if the developer is allowed to place an arbitrary sub valu=
e, but in that case the issue seem larger (eg in a grant including a user, =
placing the sub of another user). =C2=A0

We use the JWT. Sub =3D user ID. OIDC sco=
pes =3D what data is returned. This needs slightly updated logic


>* extensi=
on grants that did not use to present users
Technically we a=
re still not presenting users- the sub is the authenticated subject, which =
can be a user or an app. Here I am channeling the consensus that was reache=
d after quite a few back and forths, see=C2=A0https://mailarc=
hive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.
That=E2=80=99s fine - not tryi=
ng to change your mind


But besides the nitpicking. C=
ould you expand on the extension grants you are thinking of, and how they=
=E2=80=99d be affected?
A=
gain our internal extension grant logic is based on the existence of the su=
b claim after the response data has been generated. If sub is present we in=
voke a whole pipeline around user centric claims. Needs to be changed.
<=
p>

=
>* token exchange scenarios
This is another really intere=
sting point. I admit I haven=E2=80=99t studied the RFC and I might be remem=
bering an older version, but I believe the specs referred to principals, wh=
ich aren=E2=80=99t necessarily human; and I remember one dev from the commu=
nity describing a scenario where he would have liked to be able to do OBO w=
ith machine identities, and his scenario was reasonable.
Is ther=
e anything specific that breaks in your implementation of token exchange if=
 you have a sub not corresponding to a user?
See above.


=C2=A0
>* enforce a colli=
sion domain for sub and client_id
If your =
product allows developers to arbitrarily set values for one or both of thos=
e, I totally see how enforcement would be extra work! I would argue that in=
 that case perhaps you don=E2=80=99t have to, if the user can set arbitrary=
 values they can already do things that would break standards (like assigni=
ng the same sub to two different users) hence in that case you can=E2=80=99=
t be responsible for it at product design, it=E2=80=99s kind of up to them.=

=C2=A0
Note, I know th=
at answering the above might require extra work in investigating and writin=
g about it, I don=E2=80=99t mean to burden you with it. My aim here is unde=
rstanding whether the challenges you identified mostly stem from the underl=
ying assumption =E2=80=9Cpresence of a sub=3D>it=E2=80=99s a user=E2=80=
=9D, which is understandable but was established in the discussions referen=
ced above not to be enough to violate 7519, or if there are other factors a=
t play that introduce challenges when sub is used that way.
Thanks again for putting time in checking this and considering i=
mplementing it!
Cheers,
V.=C2=A0
=C2=A0
From:=C2=A0Dominick Baier <dbaier@leastprivilege.com>
Date:=C2=A0Monday, May 4, 2020 at 00:36
To:=C2=A0"oauth@ietf.org" <o=
auth@ietf.org>, "vittorio.bertocci@auth0.com" <vittorio.bertocci@auth0.com>
Subject:=C2=A0JWT profile and IdentityServer=

=C2=A0
Hey,=C2=
=A0
=C2=A0
Just some notes on a=
pplying the JWT profile to IdentityServer
=C2=A0
* we emit the at+jwt typ - that=E2=80=99s very useful
* we emit iat in addition to nbf (if we would remove nbf=
, we would break the .NET JWT library from Microsoft - I guess that=E2=80=
=99s the reason AAD emits it as well)
* we have an op=
tion to emit scope as a space delimited string (we used a string array for =
historic reasons - also because that=E2=80=99s how the claims plumbing in .=
NET prefers it)
=C2=A0
* aud
=C2=A0
Audience is optional in I=
dentityServer if you request scopes that do not have an association to a re=
source. I personally think this is the right way to go. You can =E2=80=9Cfo=
rce=E2=80=9D an audience even for this situation if you absolutely want to<=
/span>
=C2=A0
* sub vs client_id
=C2=A0
In IdentityServer access toke=
ns that do not have a user present, do not have a sub claim - only client_i=
d. If there is a user present, sub ALWAYS represents the user.
=C2=A0
I was prototyping a setting to emit =
the sub claim for situation where there is no user, which would not be hard=
 to do - but we found out that there are many situations where this would n=
eed VERY THOROUGH testing of all the various flows to not introduce subtle =
security bugs
=C2=A0
* the user=
 info endpoint needs to do extra checking
* extension=
 grants that did not use to present users
* token exc=
hange scenarios
* enforce a collision domain for sub =
and client_id
=C2=A0
This could=
 all be sorted probably if I would have enough time right now - but the bot=
tom line is, that this ambiguity and special casing requires careful re-wri=
ting and I guess this applies to any reasonably complex system that is alre=
ady out there. So I am still not sold that the =E2=80=9Cdual purpose=E2=80=
=9D claims are the best choice. YMMV.
=C2=A0
IOW - we will not adopt the sub/client_id semantics as propos=
ed by the document.
=C2=A0
=C2=
=A0
My 2c / cheers=C2=A0
=E2=80=94=E2=80=94=E2=80=94=C2=A0
Dominick Baier


--00000000000087c90705a4cec355--


From nobody Mon May  4 03:36:15 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6933A07A2 for ; Mon,  4 May 2020 03:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.414
X-Spam-Level: 
X-Spam-Status: No, score=0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEv6GEUCJyn1 for ; Mon,  4 May 2020 03:36:10 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510B43A0795 for ; Mon,  4 May 2020 03:36:09 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d14 with ME id aac5220184FMSmm03ac6mX; Mon, 04 May 2020 12:36:07 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 04 May 2020 12:36:07 +0200
X-ME-IP: 86.238.65.197
To: Benjamin Kaduk 
Cc: Vittorio Bertocci , "oauth@ietf.org" 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu>
From: Denis 
Message-ID: <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr>
Date: Mon, 4 May 2020 12:36:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200504055923.GH27494@kduck.mit.edu>
Content-Type: multipart/alternative; boundary="------------9C42D9EB464358BECDB6DDEA"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 10:36:14 -0000

This is a multi-part message in MIME format.
--------------9C42D9EB464358BECDB6DDEA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Benjamin,

First of all, you don't need to use an aggressive language to state your 
opinion.

Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the 
following title:"IETF Guidelines for Conduct". In particular:

    " Regardless of these individual differences, participants treat
    their colleagues with respect as persons especially
        when it is difficult to agree with them: treat other
    participants as you would like to be treated ".

I wrote:

(...)

     I will go one step further: if the client wants to inspect the 
token and
     if the format of the token is unknown to the client, then the client
will simply stop its further transmission. For some clients, preserving 
their
privacy may be more important than performing an access to a RS.

You responded :

    That may be true, but I agree with Vittorio that this document needs to
    strongly discourage clients from doing so, since they would 
be**_breaking _*
*_a __protocol invariant_ if they do.

If "this may be true", then you should consider that the token 
inspection by a client may be useful and thus should not be prevented.
However, there is no guarantee that it may always be performed.

You are using the wording" _breaking a protocol invariant_". In which 
RFC (related to OAuth) has such a "protocol invariance" been first 
mandated ?

I attempted to find an RFC using the wording "protocol invariant". I 
found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1
with the topic " Declaring Protocol Invariants", using the following terms:

Declaring a protocol's invariants represents a promise made by the 
protocol's developers that certain bits in the wire image, and behaviors
    observable in the wire image, will be preserved through the 
specification of all future versions of the protocol.

Using these explanations, I have difficulties to understand how 
preventing the content of a JWT to be inspected by a client may be 
considered
as "a promise made by the protocol's developers that certain bits in the 
wire, and behaviors observable in the wire, will be preserved
through the specification of all future versions of the protocol".

I probably missed something. Would you be able to explain ?

A second point:

As a co-author of RFC 3161 published in August 2001 and of RFC 36268 
published in November 2003 to name a few of the RFCs
to which I contributed, I am not aware of any reference to an ISO 
document made into a RFC. This seems to be a common practice.
When I used the term "refer", I was not asking to place a reference to 
an ISO document in this working draft but to allow everybody in
the WG to have the ability to have a look at its content (and for free). 
Table 3 is simply a quick "reference" to ten privacy principles.

A third point:

RFC 6973 (Privacy Considerations for Internet Protocols) has been 
published in July 2013. Its introduction mentions:

The guidance provided here can and should be used to _assess the privacy 
considerations of protocol_, architectural,
     and operational _specifications_ (...)

    The guidance provided here is meant to help the thought process of 
privacy analysis; it does not provide specific directions
     for how to write a privacy considerations section.

Section 7 (Guidelines) mentions :

    This section provides guidance for document authors in the form of a 
questionnaire about a protocol being designed.
    The questionnaire may be useful at any point in the design process, 
particularly after document authors have developed
    a high-level protocol model as described in [RFC4101].
(...)
However, by carefully considering the answers to each question, document 
authors should be able to produce a comprehensive
    analysis that can serve as the basis for discussion of whether the 
protocol adequately protects against privacy threats.

An important item which is addressed both in ISO 29100 and RFC 6973 in 
section 7.1 is "Data Minimization". RFC 6973 mentions:

a.*Identifiers*.What identifiers does the protocol use for 
distinguishing initiators of communications?
Does the protocol use identifiers that allow different protocol 
interactions to be correlated?
What identifiers could be omitted or be made less identifying while 
still fulfilling the protocol’s goals?

b.*Data*.What information does the protocol expose about individuals, 
their devices, and/or their device usage (other than the identifiers 
discussed in (a))?
      To what extent is this information linked to the identities of the 
individuals?How does the protocol combine personal data with the 
identifiers discussed in (a)?

c.*Observers*.Which information discussed in (a) and (b) is exposed to 
each other protocol entity (i.e., recipients, intermediaries, and enablers)?
Are there ways for protocol implementers to choose to limit the 
information shared with each entity?  µ
Are there operational controls available to limit the information shared 
with each entity?
(...)

e.*Persistence of identifiers*.What assumptions are made in the protocol 
design about the lifetime of the identifiers discussed in (a)?
      Does the protocol allow implementers or users to delete or replace 
identifiers?

f.*Correlation*.Does the protocol allow for correlation of 
identifiers?Are there expected ways that information exposed by the 
protocol will be combined
     or correlated with information obtained outside the protocol?

RFC 6973 also mentions in section 7.2 (User Participation) (while ISO 
29100 uses the wording "Consent and choice"):

a.*User control*.What controls or consent mechanisms does the protocol 
define or require before personal data or identifiers are shared or 
exposed via the protocol?


All the above questions are useful to assess privacy considerations 
about the protocol. Some key questions related to OAuth are the following:

  * considering the current semantics of the "sub" claim, what are the
    implications in terms of "correlation" ?
  * considering the current semantics of the scope request parameter (or
    of any other token request parameter), what are the implications in
    terms of "user control" ?

The next version of this document should use RFC 6973 more closely as a 
guidance to "_assess the privacy considerations __of the protocol_ and 
of operational _specifications_".

Denis


> Hi Denis,
>
> You seem to be continuing to be operating under incorrect assuptions about
> how OAuth 2.0 works, and have proceeded to make long chains of reasoning
> that, unfortunately, are not based on a solid foundation.  In order to
> reduce the amount of frustration amongst all participants, in the future I
> strongly suggest that you make sure you have the fundamentals correct
> before going into long chains of reasoning.
>
> Furthermore, while you have indeed identified some areas where the current
> OAuth ecosystem could be improved, I reiterate that the current document,
> defining a token format that is optional to use, is not the place to make
> changes to how OAuth works.  I think you do everyone a disservice for
> attempting to suggest that this document should do so.
>
> Because there is so much based on a flawed foundation, I will not respond
> inline to every point, but do see a few things where further clarification
> would be useful.
>
> On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
>> Hello Vittorio,
>>
>> Your reply was amazingly fast. Responses are between the lines.
>>
>>> Thanks Denis for the thorough commentary.
>>>
>>> /> The title of this spec./
>>>
>>> Fixed, thanks!
>>>
>>> /> The client MUST NOT inspect the content of the access token/
>>>
>>>
>>> This is really a sticky point. I really want to acknowledge your PoV
>>> on this, but at the same time I found this to be one of the biggest
>>> sources of issues
>>> in the use of JWT for access tokens hence I feel we really need to
>>> give solid guidance here. Let me expand further on the reasoning
>>> behind it,
>>> and perhaps we can get to language that satisfies both PoVs.
>>>
>>>
>>> To me the key point is that clients should not write /code/ that
>>> inspects access tokens. Taking a dependency on the ability to do so is
>>> ignoring fundamental information
>>> about the architecture and relationships between OAuth roles, and
>>> suggests an ability of the client to understand the semantic of the
>>> content that cannot be assumed
>>> in the general case. I expanded on the details in my former reply to
>>> you on this topic, I would recommend referring to it.
>>>
>>> Clients violating this simple principle has been one of the most
>>> common sources of production issues I had to deal with in the past few
>>> years, and one of the hardest
>>> to remediate given that clients are hard to update and sometimes the
>>> things they relied on were irremediably lost. This is why I am
>>> inclined to put in here strong language.
>>>
>>> That said: I have nothing against client developers examining a
>>> network trace and drawing conclusions based on the content of what
>>> they see. That doesn’t create any hard
>>> dependencies and has no implications in respect to changes in the
>>> solution behavior. However I am not sure how to phrase that in the
>>> specification, given that referring
>>> to the client inevitably refers to its code. I am open to suggestions.
>>>
>> First of all, a "*MUST NOT* "should not be placed in a privacy
>> considerations section, but in the main body of the document.
>> The goal of a privacy considerations section is to provide explanations,
>> but not to introduce additional requirements.
> That's not actually a requirement.  In many cases it makes sense to avoid
> putting normative requirements in the security and/or privacy
> considerations sections, but it is very much a thing that is done in many
> RFCs, and in some cases it is useful to do so.
>
>> Then after, since this section is about privacy considerations, it is
>> important to refer to an ISO standard that has been published 9 years ago.
> Is it?  I don't see much precedent for IETF documents referencing this ISO
> standard.  If it's so important you'd think that we'd have been citing it
> with regularity.  Since this will be the first or second time, I think you
> need to provide some additional justification as to how the topics it
> covers fit within the existing IETF BCPs for how we treat security and
> privacy considerations before we conclude that it is the appropriate
> reference.
>
>> It is ISO 29100 (Information technology — Security techniques — Privacy
>> framework). Most of the ISO standards need to be bought.
>> However, there are a few exceptions and this standard can be freely
>> downloaded from the ISO web site, if you accept some conditions,
>> using this URL:
>>
>>      https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
>>
>> ISO 29100, even if it is outdated on some aspects (it only deals with
>> two entities), identifies ten principles (See Table 3).
>>
>>      1. Consent and choice
>>
>>      2. Purpose legitimacy and specification
>>
>>      3. Collection limitation
>>
>>      4. Data minimization
>>
>>      5. Use, retention and disclosure limitation
>>
>>      6. Accuracy and quality
>>
>>      7. Openness, transparency and notice
>>
>>      8. Individual participation and access
>>
>>      9. Accountability
>>
>>      10. Information security
>>
>>      11. Privacy compliance
>>
>> If the client is unable to inspect the token, then openness and
>> transparency do not exist any more.
>>
>> Since there is no formal protocol in OAuth 2.0  for "consent and
>> choice", the only way for a client for denying its consent is to inspect
>> the token
>> and to stop its transmission if the content of the token is not
>> considered to be adequate for it.
>>
>> Since you are open to suggestions, would you please reconsider the text
>> I proposed: it simply states that if the client wants to inspect the token,
>> it will not necessarily be in a position to do it. It is simply a
>> warning, but this warning does not prevent the client to attempt to
>> inspect the token .
>>
>> I will go one step further: if the client wants to inspect the token and
>> if the format of the token is unknown to the client, then the client
>> will simply
>> stop its further transmission. For some clients, preserving their
>> privacy may be more important than performing an access to a RS.
> That may be true, but I agree with Vittorio that this document needs to
> strongly discourage clients from doing so, since they would be breaking a
> protocol invariant if they do.
>
> Thanks,
>
> Ben
>
>>>>   3)…
>>> I have a pretty hard time following the chain of reasoning in this
>>> section. Let me attempt to tackle it to the best of my understanding.
>>>
>>> I think the key might be
>>>
>>> /> a client should be able to choose whether it wishes the sub claim
>>> to contain [..]
>>>
>>> /
>>>
>>> I don’t think that should be a choice left to the client. In business
>>> systems, my experience is that the type of identifiers to be used
>>> (when the IdP gives any choice at all)
>>>   is established at resource provisioning time. I am not aware of
>>> mechanisms thru which a client signals the nature of the identifier to
>>> be used, nor that would be fully
>>> feasible (the resource knows what it needs to perform its function).
>>>
>> Consent and choice is the first of the ten privacy principles. Since
>> OAuth has not been constructed taking into considerations this privacy
>> principle,
>> it is quite "normal" that you don't observe protocols able to do it at
>> the present time.
>>
>>> Furthermore:
>>>
>>> /> which has nothing to do with uniqueness since the value changes for
>>> every generated token.
>>>
>>> /
>>>
>>> Again, this is something that was touched on in my former reply to
>>> your message. As long as an identifier identifies one resource only,
>>> it satisfies uniqueness. It doesn’t have to be a singleton.
>>>
>> It is a matter of interpretation. I stick to the definition given in RFC
>> 7519 (section 4.1.2):
>>
>> *T**he subject value MUST either be scoped to be locally unique in the
>> context of the issuer or be globally unique.*
>>
>> However, the "context of the issuer" is left undefined.
>>
>>> Finally, the scope is optional (for good reasons: 1^st party and non
>>> delegation scenarios don’t require it) hence it cannot be relied upon
>>> for properties that should hold in every scenario.
>>>
>> I would not say that the scope request parameter is a nice way to choose
>> which attributes should be placed in a JWT. However, considering the
>> limitations placed
>> in this document, it is the ONLY way to do. In my email sent before the
>> virtual meeting, I wrote: "Allowing a client to only specify a scope and
>> a resource is very restrictive".
>>
>> Clause 2.2.2 (second paragraph) states:
>>
>> ***This profile does not introduce any mechanism for a client to**
>> ******directly request the presence of specific claims in JWT access**
>> ******tokens*, as the authorization server can determine what additional
>> claims are required by a particular resource server by taking in
>> consideration the client_id of the client, the scope and the resource
>> parameters included in the request.
>>
>> Currently, the client has no control of the claims that will be placed
>> in a JWT and further more the current wording of privacy consideration
>> section
>> prevents the client to have any inspection of the attributes that have
>> been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not
>> fulfilled.
>>
>> There are more implications. If, in the future, a mechanism is defined
>> to allow the client to choose the type of the attributes that should be
>> placed in a JWT,
>> then the "sub" claim is insufficient. Taking into consideration my
>> previous email, four types of attributes types would need to be specified:
>>
>> The client should be able to choose whether it wishes a claim that contains:
>>
>>    *      a global unique identifier for all ASs ("globally unique"),
>>    *      a unique identifier for each AS ("locally unique in the context
>>      of the issuer"),
>>    *      a different pseudonym for each RS, or
>>    *      a different pseudonym for each authorization token request.
>>
>> Clause 2.2.2 states:
>>
>> *   the authorization server can determine what additional**
>> ******claims are required by a particular resource server* by taking in
>> consideration the client_id of the client, the scope and the resource
>> parameters included in the request.
>>
>> I don't believe this is true in general. Considering its privacy
>> preferences, only the client may know what is appropriate: not the AS,
>> neither the RS.
>>
>>> In summary: per the preceding thread on this topic, the consensus was
>>> that varying the sub content was a satisfactory way of protecting
>>> against correlation.
>>>
>> "/if all you have is a hammer, everything looks like a nail/".
>>
>> When the only parameter that can be used is the "sub" claim, then the
>> only solution is to place everything into it.
>>
>>> I don’t a gree that clients should have a mechanism to request
>>> different sub flavors, as that decision should be done out of band by
>>> the AS and RS; and the scope isn’t always available anyway.
>>>
>> While it would be nice to have such a mechanism, we are not going to
>> define such a mechanism during a second WGLC.
>>
>> The privacy considerations section should only inform the readers about
>> the limitations of the protocol in terms of privacy.
>> I have proposed text to address the point. If you would prefer a
>> different wording to address this point, please make another proposal.
>>
>>> /> targeting of access tokens/
>>>
>>> Let me think about that a bit longer.
>>>
>>> I acknowledge that the decision of including an audience has the
>>> effect of letting the AS track when the client accesses a particular
>>> resource,
>>> but at the same time that’s completely mainstream and very much by
>>> design in a very large number of cases. As such, I find the language
>>> you are suggesting to be potentially confusing, as it positions this
>>> as an exception vs a privacy protecting mainstream that is in fact not
>>> common,
>>> and ascribes to the client more latitude than I believe is legitimate
>>> to expect or grant.
>>>
>>> I’ll try to come up with concise language that clarifies to the reader
>>> that the current mechanism does allow AS tracking.
>>>
>> Please do so.
>>
>> Denis
>>
>>> *From: *OAuth  on behalf of Denis
>>> 
>>> *Date: *Wednesday, April 29, 2020 at 09:12
>>> *To: *"oauth@ietf.org" 
>>> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
>>> for OAuth 2.0 Access Tokens"
>>>
>>> You will find four comments numbered 1) to 4).
>>>
>>> *1) *The title of this spec. is:
>>>
>>> JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
>>>
>>> So, this spec. is supposed to be targeted to OAuth *2.0. * However,
>>> the header at the top of the page omits to mention it.
>>>
>>> Currently, it is :
>>>
>>> Internet-Draft OAuth Access Token JWT Profile           April 2020
>>>
>>> It should rather be:
>>>
>>> Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020
>>>
>>> *2)* The following text is within section 6.
>>>
>>> The client MUST NOT inspect the content of
>>> the access token: the authorization server and the resource server
>>> might decide to change token format at any time (for example by
>>> switching from this profile to opaque tokens) hence any logic in the
>>> client relying on the ability to read the access token content would
>>> break without recourse.
>>> Nonetheless, authorization servers should
>>> not assume that clients will comply with the above.
>>>
>>> It is of a primary importance that clients MAY be able to inspect
>>> tokens before transmitting them.
>>> The "MUST NOT" is not acceptable.
>>>
>>> The above text should be replaced with:
>>>
>>> Reading the access token content may be useful for the user to verify
>>> that
>>> the access token content matches with its expectations. However,
>>> the authorization server and the resource server might decide to
>>> change the
>>> token format at any time.  Thus, the client should not expect to
>>> always be
>>> in a position to read the access token content.
>>>
>>> The remaining of the text about this topic is fine.
>>>
>>>
>>> *3) *The next topic is about the sub claim.
>>>
>>> The text states:
>>>
>>> Although the ability to correlate requests might be required by
>>> design in many scenarios, there are scenarios where the authorization
>>> server might want to prevent correlation to preserve the desired
>>> level of privacy. Authorization servers should choose how to assign
>>> sub values according to the level of privacy required by each
>>> situation.
>>>
>>> I have a set of questions:
>>>
>>>   1. How can authorization servers choose how to assign sub values
>>>      according to the level of privacy required "by each situation" ?
>>>   2. How can authorization servers know the level of privacy required
>>>      "by each situation" ?
>>>   3. How can the users be informed of the level of privacy required "by
>>>      each situation" ?
>>>   4. How can the users *consent* with the level of privacy required "by
>>>      each situation" ?
>>>
>>> Currently, the request MUST include either a resource parameter or an
>>> aud claim parameter, while it MAY include a scope parameter.
>>>
>>> The syntax of the scope parameter is a list of space-delimited,
>>> case-sensitive strings (RFC 6749). It is thus subject to private
>>> agreements
>>> between clients and Authorization Servers. Since the scope is being
>>> returned, it is a primary importance that the returned scope matches
>>> with its expectations before transmitting the token to a Resource Server.
>>>
>>> In theory, a client should be able to choose whether it wishes the sub
>>> claim to contain :
>>>
>>>    * a global unique identifier for all ASs ("globally unique"),
>>>    * a unique identifier for each AS ("locally unique in the context of
>>>      the issuer"),
>>>    * a different pseudonym for each RS, or
>>>    * a different pseudonym for each authorization token request.
>>>
>>> The only variable parameter that it can use for this purpose in the
>>> token request is the scope parameter.
>>>
>>> RFC 7519 states is section 4.1.2:
>>>
>>> The subject value MUST either be scoped to be locally unique in the
>>> context of the issuer
>>> or be globally unique.
>>>
>>> It is quite hard to recognize that the sub claim is able to carry a
>>> different pseudonym for each RS, i.e. for case (c), or
>>> a different pseudonym for each authorization token request, i.e. for
>>> case (d), which has nothing to do with uniqueness
>>> since the value changes for every generated token.
>>>
>>> This has implications about the following text:
>>>
>>> For instance: if a solution requires preventing tracking
>>> principal activities across multiple resource servers, the
>>> authorization server should ensure that JWT access tokens meant for
>>> different resource servers have distinct sub values that cannot be
>>> correlated in the event of resource servers collusion.
>>>
>>> Since it addresses case (c).
>>>
>>> and also about the following text:
>>>
>>> 4.b) Similarly: if a solution requires preventing a resource server from
>>> correlating the principal’s activity within the resource itself, the
>>> authorization server should assign different sub values for every JWT
>>> access token issued.
>>>
>>> Since it addresses case (d).
>>>
>>> This means that the current text placed in the privacy considerations
>>> section was a good attempt to address the case,
>>> but that the text needs to be revised.
>>>
>>> Proposed text replacement for all the previously quoted sentences:
>>>
>>> According to RFC 7519 (4.1.2): The subject value MUST either be scoped
>>> to be locally unique in the context of the issuer or be globally unique.
>>>
>>> When the sub claim contains a globally unique identifier, this allows
>>> to correlate principal activities across multiple resource servers,
>>> while in addition,
>>> this globally unique identifier may also allow to correlate the
>>> principal activities on servers where no access has been performed by
>>> the principals
>>> to these servers but where the same globally unique identifiers are
>>> being used by these servers.
>>>
>>> When the sub claim contains a locally unique identifier in the context
>>> of the issuer, this also allows the tracking of principal activities
>>> across multiple resource servers.
>>>
>>> The scope request parameter is the only way to influence on the
>>> content of the sub claim parameter. Its meaning is subject to a
>>> private agreement
>>> between the client and the AS, which means that the use of the scope
>>> parameter is the only way to choose between a locally unique identifier
>>> in the context of the issuer or a globally unique identifier.
>>>
>>> Since the scope parameter is being returned, it is a primary
>>> importance that the returned scope matches with the expectations of
>>> the client before transmitting
>>> the token to a Resource Server.
>>>
>>> However, there are other cases where the client would like to be able
>>> to choose whether it wishes the sub claim to contain :
>>>      - a different pseudonym for each RS so that different resource
>>> servers will be unable to correlate its activities, or
>>>      - a different pseudonym for each authorization token request, so
>>> that the same resource server cannot correlate its activities
>>> performed at different instant of time.
>>>
>>> Considering the semantics of the sub claim, these two cases cannot be
>>> currently supported.
>>>
>>>
>>> *4) *The next topic is about the targeting of access tokens
>>>
>>> Text had been proposed before the last conference call. Then, the
>>> topic has been presented at the very end of the last conference call,
>>> but no text has been included
>>> in the next draft.
>>>
>>> Here is a revised text be included in the privacy considerations section:
>>>
>>> For security reasons, some clients may be willing to target their
>>> access tokens but, for privacy reasons, may be unwilling to disclose
>>> to Authorization Servers
>>> an identification of the Resource Servers they are going to access, so
>>> that Authorization Servers will be unable to know which resources
>>> servers are being accessed.
>>> The disclosure of the Resource Servers names allows the Authorization
>>> Servers to list all the Resource Servers being access by all its users
>>> and in addition to list pairs
>>> of (Principal, Resource Servers) which allow to trace all the users
>>> accesses to Resource Servers performed through a given Authorization
>>> Server. When a token is targeted,
>>> this profile does not contain provisions to address these two threats.
>>>
>>> Denis
>>>
>>>      Hi all,
>>>
>>>      This is a second working group last call for "JSON Web Token (JWT)
>>>      Profile for OAuth 2.0 Access Tokens".
>>>
>>>      Here is the document:
>>>
>>>      https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>>>
>>>      Please send your comments to the OAuth mailing list by April 29, 2020.
>>>
>>>      Regards,
>>>
>>>       Rifaat & 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



--------------9C42D9EB464358BECDB6DDEA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Benjamin,

    


      

    
First of all, you don't need to use an
        aggressive language to state your
        opinion.

      

      Please follow BCP 54, i.e. RFC 7154, issued in March 2014 with the following
        title: "IETF Guidelines for Conduct". In
        particular:

    

      
" Regardless of these individual
          differences, participants treat their colleagues with respect
          as persons especially 

             when it is difficult to agree with them: treat other
          participants as you would like to be treated ".

    

    

      

          I wrote:

      
   
          (...)

          

      
    I will go
            one step further: if the client wants to inspect the token
            and 

            if the
            format of the token is unknown to the client, then the
            client 

           
            will simply stop its further transmission. For some clients,
            preserving their 

           
            privacy may be more important than performing an access to a
            RS.

        
          

          You responded :

        

      
   That may be true, but I agree with
          Vittorio that this document needs to

             strongly discourage clients from doing so, since they would
          be breaking 

               a protocol invariant if they do.

        

      
If "this may be true", then you should
          consider that the token
          inspection by a client may be useful and thus should not be
          prevented.

          However, there is no guarantee that it may always be
          performed.

        

      

          You are using the wording" breaking a protocol invariant".
          In
          which RFC (related to OAuth) has such a "protocol invariance"
          been first
          mandated ?

      

          I attempted to find an RFC using the wording "protocol
          invariant". I
          found RFC 8546 (Wire Image) issued in April 2019 dealing in
          section 4.1

          with
          the topic " Declaring Protocol Invariants", using the
          following
          terms:

          

             
          Declaring a protocol's invariants represents a promise made by
          the protocol's
          developers that certain bits in the wire image, and behaviors
          

             observable in the
          wire image, will be preserved through the specification of all
          future versions
          of the protocol. 

        

      

          Using these explanations, I have difficulties to understand
          how preventing the
          content of a JWT to be inspected by a client may be considered
          

          as "a promise made by the
          protocol's developers that certain bits in the wire, and
          behaviors observable
          in the wire, will be preserved 

          through the specification of all future versions
          of the protocol". 

        

      
I probably missed something. Would you be
          able to explain ?

        

      
A second point:

        

      
As a co-author of RFC 3161 published in
          August 2001 and of RFC 36268 published
          in November 2003 to name a few of the RFCs 

          to which I contributed, I am not
          aware of any reference to an ISO document made into a RFC.
          This seems to be a common
          practice. 

          When I used the term "refer", I was not asking to place a
          reference to an ISO document in this working draft but to
          allow everybody in
          

          the WG to have the ability to have a look at its content (and
          for free). Table 3 is simply a quick "reference" to ten
          privacy principles. 

        

      
A third point:

        

      
RFC 6973 (Privacy Considerations for
          Internet Protocols) has been published in
          July 2013. Its introduction mentions:

          

             
          The guidance provided here can and should be used to assess
            the privacy
            considerations of protocol, architectural, 

              and operational specifications (...)

             
          

             The guidance provided here is meant to help the thought
          process of privacy
          analysis; it does not provide specific directions 

              for how to write a privacy
          considerations section.

          

          Section 7 (Guidelines) mentions :

          

             This section provides guidance for document authors in the
          form of a
          questionnaire about a protocol being designed. 
          

             The questionnaire may be useful at any point in the design
          process,
          particularly after document authors have developed

             a high-level protocol model
          as described in [RFC4101].

            
          (...) 

             However, by carefully
                considering the answers to each question, document
                authors should be able to
                produce a comprehensive 

                   analysis that can serve as the basis for discussion
                of
                whether the protocol adequately protects against privacy
                threats.  

        

      
An important item which is addressed both
          in ISO 29100 and RFC 6973 in section
          7.1 is "Data Minimization". RFC 6973 mentions:

          

          a.  Identifiers.  What identifiers does
          the protocol use for
          distinguishing initiators of communications? 
            

                 Does the
            protocol
            use identifiers that allow different protocol interactions
            to be
            correlated?  

            What identifiers could be
            omitted or be made less identifying while still fulfilling
            the protocol’s
            goals?

          

          b.  Data.  What information does
          the protocol expose
          about individuals, their devices, and/or their device usage
          (other than the
          identifiers discussed in (a))? 
          

                 To what extent is this
            information linked to the identities of the individuals?  How does the protocol
          combine personal data
          with the identifiers discussed in (a)?

        

      
c.  Observers.  Which information
          discussed in (a) and (b)
          is exposed to each other protocol entity (i.e., recipients,
          intermediaries, and
          enablers)? 

                 Are there ways for protocol
            implementers to choose
            to limit the information shared with each entity?  µ

                Are there operational controls available to limit
            the information
            shared with each entity?

             
          (...)

          

          e.  Persistence of
            identifiers.  What assumptions are made in the protocol design
            about the lifetime of
            the identifiers discussed in (a)? 
          

               Does the protocol allow implementers or users to delete
          or replace
          identifiers?

          

          f.  Correlation.  Does the protocol allow
          for correlation of
          identifiers?  Are there expected ways that
            information exposed
            by the protocol will be combined 

                or correlated with information obtained
            outside the protocol? 

        

      
RFC 6973 also mentions in section 7.2
          (User Participation) (while ISO 29100
          uses the wording "Consent and choice"):

          

          a.  User control.  What controls or consent mechanisms does the
            protocol define or require
            before personal data or identifiers are shared or exposed
            via the protocol?
          

        

      


          All the above questions are useful to assess privacy
          considerations about the protocol. Some key
          questions related to OAuth are the following: 

        

      
    
        
  • 
            considering the current semantics of the "sub" claim, what
            are the
            implications in terms of "correlation" ?
    
          
    • 
        
  • 
            considering the current semantics of the scope request
            parameter (or of any
            other token request parameter), what are the implications in
            terms of
            "user control" ?
    • 
      

      
The next version of this document should
          use RFC 6973 more closely as a guidance to "assess the privacy
              considerations of the protocol and of
            operational specifications".
        

      
Denis

      


        

    

    

      
Hi Denis,

You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation.  In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.

Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works.  I think you do everyone a disservice for
attempting to suggest that this document should do so.

Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.

On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:


      

        
Hello Vittorio,

Your reply was amazingly fast. Responses are between the lines.



        

          
Thanks Denis for the thorough commentary.

/> The title of this spec./

Fixed, thanks!



        

        

        

          
/> The client MUST NOT inspect the content of the access token/


This is really a sticky point. I really want to acknowledge your PoV 
on this, but at the same time I found this to be one of the biggest 
sources of issues
in the use of JWT for access tokens hence I feel we really need to 
give solid guidance here. Let me expand further on the reasoning 
behind it,
and perhaps we can get to language that satisfies both PoVs.


To me the key point is that clients should not write /code/ that 
inspects access tokens. Taking a dependency on the ability to do so is 
ignoring fundamental information
about the architecture and relationships between OAuth roles, and 
suggests an ability of the client to understand the semantic of the 
content that cannot be assumed
in the general case. I expanded on the details in my former reply to 
you on this topic, I would recommend referring to it.

Clients violating this simple principle has been one of the most 
common sources of production issues I had to deal with in the past few 
years, and one of the hardest
to remediate given that clients are hard to update and sometimes the 
things they relied on were irremediably lost. This is why I am 
inclined to put in here strong language.

That said: I have nothing against client developers examining a 
network trace and drawing conclusions based on the content of what 
they see. That doesn’t create any hard
dependencies and has no implications in respect to changes in the 
solution behavior. However I am not sure how to phrase that in the 
specification, given that referring
to the client inevitably refers to its code. I am open to suggestions.



        

        
First of all, a "*MUST NOT* "should not be placed in a privacy 
considerations section, but in the main body of the document.
The goal of a privacy considerations section is to provide explanations, 
but not to introduce additional requirements.


      

      
That's not actually a requirement.  In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.



      

        
Then after, since this section is about privacy considerations, it is 
important to refer to an ISO standard that has been published 9 years ago.


      

      
Is it?  I don't see much precedent for IETF documents referencing this ISO
standard.  If it's so important you'd think that we'd have been citing it
with regularity.  Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.



      

        
It is ISO 29100 (Information technology — Security techniques — Privacy 
framework). Most of the ISO standards need to be bought.
However, there are a few exceptions and this standard can be freely 
downloaded from the ISO web site, if you accept some conditions,
using this URL:

    https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

ISO 29100, even if it is outdated on some aspects (it only deals with 
two entities), identifies ten principles (See Table 3).

    1. Consent and choice

    2. Purpose legitimacy and specification

    3. Collection limitation

    4. Data minimization

    5. Use, retention and disclosure limitation

    6. Accuracy and quality

    7. Openness, transparency and notice

    8. Individual participation and access

    9. Accountability

    10. Information security

    11. Privacy compliance

If the client is unable to inspect the token, then openness and 
transparency do not exist any more.

Since there is no formal protocol in OAuth 2.0  for "consent and 
choice", the only way for a client for denying its consent is to inspect 
the token
and to stop its transmission if the content of the token is not 
considered to be adequate for it.

Since you are open to suggestions, would you please reconsider the text 
I proposed: it simply states that if the client wants to inspect the token,
it will not necessarily be in a position to do it. It is simply a 
warning, but this warning does not prevent the client to attempt to 
inspect the token .

I will go one step further: if the client wants to inspect the token and 
if the format of the token is unknown to the client, then the client 
will simply
stop its further transmission. For some clients, preserving their 
privacy may be more important than performing an access to a RS.


      

      
That may be true, but I agree with Vittorio that this document needs to
strongly discourage clients from doing so, since they would be breaking a
protocol invariant if they do.

Thanks,

Ben



      

        

          

            
 3)…


          

          
I have a pretty hard time following the chain of reasoning in this 
section. Let me attempt to tackle it to the best of my understanding.

I think the key might be

/> a client should be able to choose whether it wishes the sub claim 
to contain [..]

/

I don’t think that should be a choice left to the client. In business 
systems, my experience is that the type of identifiers to be used 
(when the IdP gives any choice at all)
 is established at resource provisioning time. I am not aware of 
mechanisms thru which a client signals the nature of the identifier to 
be used, nor that would be fully
feasible (the resource knows what it needs to perform its function).



        

        
Consent and choice is the first of the ten privacy principles. Since 
OAuth has not been constructed taking into considerations this privacy 
principle,
it is quite "normal" that you don't observe protocols able to do it at 
the present time.



        

          
Furthermore:

/> which has nothing to do with uniqueness since the value changes for 
every generated token.

/

Again, this is something that was touched on in my former reply to 
your message. As long as an identifier identifies one resource only, 
it satisfies uniqueness. It doesn’t have to be a singleton.



        

        
It is a matter of interpretation. I stick to the definition given in RFC 
7519 (section 4.1.2):

*T**he subject value MUST either be scoped to be locally unique in the 
context of the issuer or be globally unique.*

However, the "context of the issuer" is left undefined.



        

          
Finally, the scope is optional (for good reasons: 1^st party and non 
delegation scenarios don’t require it) hence it cannot be relied upon 
for properties that should hold in every scenario.



        

        
I would not say that the scope request parameter is a nice way to choose 
which attributes should be placed in a JWT. However, considering the 
limitations placed
in this document, it is the ONLY way to do. In my email sent before the 
virtual meeting, I wrote: "Allowing a client to only specify a scope and 
a resource is very restrictive".

Clause 2.2.2 (second paragraph) states:

***This profile does not introduce any mechanism for a client to**
******directly request the presence of specific claims in JWT access**
******tokens*, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Currently, the client has no control of the claims that will be placed 
in a JWT and further more the current wording of privacy consideration 
section
prevents the client to have any inspection of the attributes that have 
been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not 
fulfilled.

There are more implications. If, in the future, a mechanism is defined 
to allow the client to choose the type of the attributes that should be 
placed in a JWT,
then the "sub" claim is insufficient. Taking into consideration my 
previous email, four types of attributes types would need to be specified:

The client should be able to choose whether it wishes a claim that contains:

  *      a global unique identifier for all ASs ("globally unique"),
  *      a unique identifier for each AS ("locally unique in the context
    of the issuer"),
  *      a different pseudonym for each RS, or
  *      a different pseudonym for each authorization token request.

Clause 2.2.2 states:

*   the authorization server can determine what additional**
******claims are required by a particular resource server* by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

I don't believe this is true in general. Considering its privacy 
preferences, only the client may know what is appropriate: not the AS, 
neither the RS.



        

          
In summary: per the preceding thread on this topic, the consensus was 
that varying the sub content was a satisfactory way of protecting 
against correlation.



        

        
"/if all you have is a hammer, everything looks like a nail/".

When the only parameter that can be used is the "sub" claim, then the 
only solution is to place everything into it.



        

          
I don’t a gree that clients should have a mechanism to request 
different sub flavors, as that decision should be done out of band by 
the AS and RS; and the scope isn’t always available anyway.



        

        
While it would be nice to have such a mechanism, we are not going to 
define such a mechanism during a second WGLC.

The privacy considerations section should only inform the readers about 
the limitations of the protocol in terms of privacy.
I have proposed text to address the point. If you would prefer a 
different wording to address this point, please make another proposal.



        

          
/> targeting of access tokens/

Let me think about that a bit longer.

I acknowledge that the decision of including an audience has the 
effect of letting the AS track when the client accesses a particular 
resource,
but at the same time that’s completely mainstream and very much by 
design in a very large number of cases. As such, I find the language
you are suggesting to be potentially confusing, as it positions this 
as an exception vs a privacy protecting mainstream that is in fact not 
common,
and ascribes to the client more latitude than I believe is legitimate 
to expect or grant.

I’ll try to come up with concise language that clarifies to the reader 
that the current mechanism does allow AS tracking.



        

        
Please do so.

Denis



        

          
*From: *OAuth <oauth-bounces@ietf.org> on behalf of Denis 
<denis.ietf@free.fr>
*Date: *Wednesday, April 29, 2020 at 09:12
*To: *"oauth@ietf.org" <oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
for OAuth 2.0 Access Tokens"

You will find four comments numbered 1) to 4).

*1) *The title of this spec. is:

JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens

So, this spec. is supposed to be targeted to OAuth *2.0. * However, 
the header at the top of the page omits to mention it.

Currently, it is :

Internet-Draft OAuth Access Token JWT Profile           April 2020

It should rather be:

Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020

*2)* The following text is within section 6.

The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (for example by
switching from this profile to opaque tokens) hence any logic in the
client relying on the ability to read the access token content would
break without recourse.
Nonetheless, authorization servers should
not assume that clients will comply with the above.

It is of a primary importance that clients MAY be able to inspect 
tokens before transmitting them.
The "MUST NOT" is not acceptable.

The above text should be replaced with:

Reading the access token content may be useful for the user to verify 
that
the access token content matches with its expectations. However,
the authorization server and the resource server might decide to 
change the
token format at any time.  Thus, the client should not expect to 
always be
in a position to read the access token content.

The remaining of the text about this topic is fine.


*3) *The next topic is about the sub claim.

The text states:

Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the authorization
server might want to prevent correlation to preserve the desired
level of privacy. Authorization servers should choose how to assign
sub values according to the level of privacy required by each
situation.

I have a set of questions:

 1. How can authorization servers choose how to assign sub values
    according to the level of privacy required "by each situation" ?
 2. How can authorization servers know the level of privacy required
    "by each situation" ?
 3. How can the users be informed of the level of privacy required "by
    each situation" ?
 4. How can the users *consent* with the level of privacy required "by
    each situation" ?

Currently, the request MUST include either a resource parameter or an 
aud claim parameter, while it MAY include a scope parameter.

The syntax of the scope parameter is a list of space-delimited, 
case-sensitive strings (RFC 6749). It is thus subject to private 
agreements
between clients and Authorization Servers. Since the scope is being 
returned, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.

In theory, a client should be able to choose whether it wishes the sub 
claim to contain :

  * a global unique identifier for all ASs ("globally unique"),
  * a unique identifier for each AS ("locally unique in the context of
    the issuer"),
  * a different pseudonym for each RS, or
  * a different pseudonym for each authorization token request.

The only variable parameter that it can use for this purpose in the 
token request is the scope parameter.

RFC 7519 states is section 4.1.2:

The subject value MUST either be scoped to be locally unique in the 
context of the issuer
or be globally unique.

It is quite hard to recognize that the sub claim is able to carry a 
different pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for 
case (d), which has nothing to do with uniqueness
since the value changes for every generated token.

This has implications about the following text:

For instance: if a solution requires preventing tracking
principal activities across multiple resource servers, the
authorization server should ensure that JWT access tokens meant for
different resource servers have distinct sub values that cannot be
correlated in the event of resource servers collusion.

Since it addresses case (c).

and also about the following text:

4.b) Similarly: if a solution requires preventing a resource server from
correlating the principal’s activity within the resource itself, the
authorization server should assign different sub values for every JWT
access token issued.

Since it addresses case (d).

This means that the current text placed in the privacy considerations 
section was a good attempt to address the case,
but that the text needs to be revised.

Proposed text replacement for all the previously quoted sentences:

According to RFC 7519 (4.1.2): The subject value MUST either be scoped 
to be locally unique in the context of the issuer or be globally unique.

When the sub claim contains a globally unique identifier, this allows 
to correlate principal activities across multiple resource servers, 
while in addition,
this globally unique identifier may also allow to correlate the 
principal activities on servers where no access has been performed by 
the principals
to these servers but where the same globally unique identifiers are 
being used by these servers.

When the sub claim contains a locally unique identifier in the context 
of the issuer, this also allows the tracking of principal activities 
across multiple resource servers.

The scope request parameter is the only way to influence on the 
content of the sub claim parameter. Its meaning is subject to a 
private agreement
between the client and the AS, which means that the use of the scope 
parameter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.

Since the scope parameter is being returned, it is a primary 
importance that the returned scope matches with the expectations of 
the client before transmitting
the token to a Resource Server.

However, there are other cases where the client would like to be able 
to choose whether it wishes the sub claim to contain :
    - a different pseudonym for each RS so that different resource 
servers will be unable to correlate its activities, or
    - a different pseudonym for each authorization token request, so 
that the same resource server cannot correlate its activities 
performed at different instant of time.

Considering the semantics of the sub claim, these two cases cannot be 
currently supported.


*4) *The next topic is about the targeting of access tokens

Text had been proposed before the last conference call. Then, the 
topic has been presented at the very end of the last conference call, 
but no text has been included
in the next draft.

Here is a revised text be included in the privacy considerations section:

For security reasons, some clients may be willing to target their 
access tokens but, for privacy reasons, may be unwilling to disclose 
to Authorization Servers
an identification of the Resource Servers they are going to access, so 
that Authorization Servers will be unable to know which resources 
servers are being accessed.
The disclosure of the Resource Servers names allows the Authorization 
Servers to list all the Resource Servers being access by all its users 
and in addition to list pairs
of (Principal, Resource Servers) which allow to trace all the users 
accesses to Resource Servers performed through a given Authorization 
Server. When a token is targeted,
this profile does not contain provisions to address these two threats.

Denis

    Hi all,

    This is a second working group last call for "JSON Web Token (JWT)
    Profile for OAuth 2.0 Access Tokens".

    Here is the document:

    https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

    Please send your comments to the OAuth mailing list by April 29, 2020.

    Regards,

     Rifaat & Hannes



    _______________________________________________

    OAuth mailing list

    OAuth@ietf.org  <mailto:OAuth@ietf.org>

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



        

        

      

      

      

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


      

      

    

    


    

  


--------------9C42D9EB464358BECDB6DDEA--


From nobody Mon May  4 04:51:00 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA6D3A080E for ; Mon,  4 May 2020 04:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3a96uleAdAm for ; Mon,  4 May 2020 04:50:55 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5083A0810 for ; Mon,  4 May 2020 04:50:54 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id s8so10227463wrt.9 for ; Mon, 04 May 2020 04:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YHah0nfcXyqk9gKqXhyzT1c2UPU6IupQqu7JTlXt/No=; b=CJt9A1xPyCQVACjTEKy+atKuTEtk5s1Z4AXtwbUaIPs3iMWjUrHcZ1sDmjp+OZVN9E aDO5Vzx1CvnsP7whPxiwHNiwYP/7rXaPMOFEin/vHUoOvsh7EIHXjd0Fs0QI+UTcwaKR pr8Nzuh2wpQ72e+m0U4Grx4qRWBXrm6ouV2Jk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YHah0nfcXyqk9gKqXhyzT1c2UPU6IupQqu7JTlXt/No=; b=KDzTR9VgLEFqIlNR63R3ahXAiaFPGclW+qSY09lSfya6yNFVftmzISQkAb1w6l5GVv ckqRbI8Mmso2l521TK+qsjYI2COOs2rl7+3nfeUnR3ZnrQVipl7ICzm2rDyEq3i47ebp T8jn2SvMItp04mXrQPL3khP1AIE6C0hEYjR1wBYFXQcHHXsrYKNzIv6bLfXeX1vb5xT/ UwwJYfqxJLENL9Y22N11BtMeeUjw4Yioj569zCGWZeU2y0AUPUYsN4h6J744KeJUJj4Q WHghSpyAXOdOaaB4rInBv24nvEMcBwetyj3UUwlcpgB5GBlZO0FFQ/pdUm9pcnCS5z6f 2lwQ==
X-Gm-Message-State: AGi0PuZg5UytO+j0cHNLteYP4/6jQwHQ2NwNMpPlgvFG+t090qbkZg1U cWbdoSDPR4HsNpMb5mVDK18qqw==
X-Google-Smtp-Source: APiQypLZTx5Cb2et0CHbCwsAOaoi6TuaGTuK7XXzTlzMV3KAujzt/wNv6H297mgdXOa0H9AEvEDNQw==
X-Received: by 2002:a5d:4284:: with SMTP id k4mr3685401wrq.284.1588593052818;  Mon, 04 May 2020 04:50:52 -0700 (PDT)
Received: from [10.0.0.2] (193.207.159.143.dyn.plus.net. [143.159.207.193]) by smtp.gmail.com with ESMTPSA id s24sm13341098wmj.28.2020.05.04.04.50.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2020 04:50:52 -0700 (PDT)
From: Neil Madden 
Message-Id: <55D70F29-CF65-405B-AAE0-4978C25C8FCF@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF8A8D60-44AD-4553-BB37-516FE6AEC9A7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 4 May 2020 12:50:51 +0100
In-Reply-To: 
Cc: oauth 
To: Brian Campbell 
References: <158835743733.12112.7484502726888997082@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 11:50:59 -0000

--Apple-Mail=_FF8A8D60-44AD-4553-BB37-516FE6AEC9A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Some review comments:

Section 1:
I think terms like =E2=80=9Crelatively simple=E2=80=9D are subjective =
and should be left out. I don=E2=80=99t think the machinery of JWS =
signature verification (and associated security issues) is necessarily =
simple at all.

=E2=80=9Cstronger methods =E2=80=A6 such as [RFC8705] or [token =
binding]=E2=80=9D
I would dispute that these are actually stronger methods in the context =
of an SPA, putting aside the usability issues. As has been discussed =
before, TLS is a shared context in a web browser - the same TLS =
connection will be reused for all requests, regardless of the origin =
they come from. The situation is better for cert-bound ATs because you =
need the CORS Access-Control-Allow-Credentials to be set to make a =
cross-origin request with a client certificate, but as I describe below =
there are also other attacks against TLS that don=E2=80=99t apply to =
DPoP (and would be a good reason to adopt DPoP).=20

I think this section should also mention mobile use-cases, as IMO the =
case for DPoP is much stronger in those environments. Many of our =
customers are looking for a PoP solution for mobile and have rejected =
mTLS for various reasons (which have previously been discussed on this =
list, e.g. incompatible middleboxes). DPoP is potentially really nice =
for these environments as they often have a nice secure element =
available to store the private key and are much less susceptible to XSS =
and so on, but may still worry about a malicious RS. IoT applications =
may also be a use-case as requests are often relayed over multiple hops =
and different transport protocols, so TLS cannot be used for end-to-end =
security (although in that case you probably want a full request signing =
approach).

Section 2:
I think the =E2=80=9CMain Objective=E2=80=9D in section 2 could be =
improved. The vast majority of the mechanisms described in the draft do =
nothing to address this main objective, and are in fact intended to =
prevent DPoP proof replay which is relegated to a =E2=80=9Csecondary =
objective=E2=80=9D in section 9. Only the =E2=80=9Chtu=E2=80=9D claim =
really has anything at all to do with the main objective. I think some =
of these secondary objectives, especially the anti-replay one, should be =
brought forward to section 2 to better justify what follows.

It has been mentioned several times on this list that an audience =
restriction in the AT would also solve this main objective, and the =
response has generally been that adding audience restrictions is hard in =
practice - e.g. due to the AS not knowing where the AT is intended to be =
used. I think it would be useful to explicitly add some discussion of =
this, and perhaps a comparison with things like resource indicators that =
presumably could solve at least some of the issues with audience =
restrictions.

I think there *are* significant advantages of DPoP that address =
real-world attacks that cannot be solved in any other way currently. For =
example, I was reading [1] recently about CRIME/BREACH attacks against =
CSRF tokens and it occurred to me that exactly the same kind of attack =
is a real threat to access tokens in a browser and that DPoP is an =
effective mitigation against it. To summarise, these attacks exploit =
vulnerabilities in TLS when combined with compression (either in TLS =
itself or HTTP compression) and can allow an attacker to steal bearer =
tokens or cookies after observing enough requests with the same token =
(and being able to influence some other content in the same =
request/response). One recommended mitigation is to randomize tokens so =
that they are different on every request, which thwarts the attack. =
Although DPoP doesn=E2=80=99t directly randomize the AT the AT is =
useless without a DPoP proof and a unique =E2=80=9Cjti=E2=80=9D claim =
ensures that the DPoP proof is randomized and so not recoverable through =
this attack. Given that BREACH is largely unmitigated in practice, due =
to the usefulness of compression, adding a description of this attack to =
the justification would IMO significantly improve the rationale for =
DPoP.

Section 3:
The second bullet point of step (B) isn=E2=80=99t clear - is it implying =
that refresh tokens for confidential clients shouldn=E2=80=99t be =
DPoP-bound? Must not?

Step (C) implies that only JWT-structured ATs or token introspection are =
supported for communicating the public key. Presumably deployers are =
free to use another secure mechanism if they wish?

The last bullet point about requiring a DPoP proof for refresh tokens is =
ambiguous about what happens in the case of confidential clients if the =
refresh token is not DPoP-bound. Do they not supply a DPoP proof at all =
(and it reuses the original one), or must they supply a new one? Can =
they supply a *different* DPoP proof to e.g. rotate their key pair?

Section 4:
Maybe a forward reference to section 6 when mentioning the DPoP header =
field, as that=E2=80=99s where it is defined.

4.1:
I=E2=80=99m not keen about including the full =E2=80=9Cjwk=E2=80=9D in =
every DPoP proof. It never changes for the life of the AT and adds =
considerable overhead to the size of the proof. If the RS is using token =
introspection (with opaque ATs) then it would be much more efficient to =
return the JWK in the token introspection response and let the RS cache =
that. Alternatively the AS could publish the JWK under a URL on behalf =
of the client and include a =E2=80=9Cjku=E2=80=9D header instead.

In the last paragraph, is it worth explicitly calling out things like =
GraphQL as not suitable for DPoP due to the fact that they reuse the =
same URI and HTTP method for all requests?

4.2:
I feel like this section should contain a forward reference to section =
6, otherwise it appears to suggest that verifying the signature and =
claims is sufficient - without the crucial step of ensuring that the JWK =
matches the actual access token. The potential for implementers to get =
this wrong is another reason to prefer not including the JWK directly in =
the DPoP proof but instead have it retrieved from the access token =
(either as a cnf or from token introspection). That makes it much harder =
to validate a proof that is unrelated to the AT.

Step 6 - HTTP methods are case-sensitive [2] so this check should also =
be.

Step 7 - It might be worth explicitly clarifying that =E2=80=9CHTTP =
URI=E2=80=9D means HTTPS.

Section 5:
Can we move the definition of the DPoP header syntax (currently in =
section 6) into its own section before here?

In the last paragraph delete =E2=80=9Cby a public client":

   When a DPoP-bound refresh token is used at the token endpoint by a
   public client, the AS MUST ensure that the DPoP proof contains the
   same public key as the one the refresh token is bound to.  The access
   token issued MUST be bound to the public key contained in the DPoP
   proof.

If a DPoP-bound RT is used then the AS should verify the DPoP proof =
matches the one bound to the RT regardless of which client presented it. =
(Otherwise a confidential client could steal RTs from a public client =
and circumvent the DPoP binding).

Is it worth explicitly mentioning at some point that the AS =
*shouldn=E2=80=99t* try to enforce any DPoP binding at the introspection =
endpoint? We=E2=80=99ve actually had bugs raised from people believing =
that we should enforce this for mTLS, not realising the chicken-and-egg =
situation that would create.

Section 6:
I may have missed it, but has there been any discussion of using a =
parameter on the Authorization header rather than an entirely separate =
header? For example:

Authorization: DPoP at=3D=E2=80=A6,proof=3D=E2=80=A6

Appendix A of RFC 7235 describes the use of token68 syntax for =
=E2=80=9Clegacy=E2=80=9D authentication schemes, so I assume the =
authparam syntax is preferred now and this would avoid adding another =
header (but it does mean that header might get very large if the AT is =
also a JWT, potentially exceeding size limits in servers/proxies).

(It=E2=80=99s also weird to explicitly define the syntax as token68 even =
though we know it's a JWT and will never contain some of those chars).

The example uses a JWT AT, which is needlessly confusing. I think using =
a short reference-based AT in this example would both reduce the size =
and also make clear that the DPoP proof goes in the DPoP header not the =
Authorization header.

Section 7:
As mentioned earlier, I=E2=80=99d prefer that the full JWK be included =
in the =E2=80=9Ccnf=E2=80=9D rather than a hash, but if we=E2=80=99re =
going to use a hash can we be explicit and use =E2=80=9Cjkt#S256=E2=80=9D =
please?

Section 8:
Is the AS also allowed to return a WWW-Authenticate challenge with an =
algs attribute if the client sends a proof with an unsupported =
algorithm?

Section 9:
DPoP is not incompatible with TLS-based methods, and has advantages over =
them. I think the wording here should leave open the idea that you could =
actually use both.

9.1:
This would be a good place to mention BREACH as an example of how a DPoP =
proof (and AT) might leak, despite only being sent over a direct HTTPS =
channel. Note though that adding a random jti is an effective defence =
against this even if the server doesn=E2=80=99t check it.

9.2:
Maybe mention that clients should avoid reusing the same key for other =
JWTs too?

[1]: =
https://blog.hboeck.de/archives/900-Generating-CRIME-safe-CSRF-Tokens.html=
 =
=20
[2]: https://tools.ietf.org/html/rfc7230#section-3.1.1 =


Cheers,

Neil


> On 1 May 2020, at 20:03, Brian Campbell =
 wrote:
>=20
> I've pushed out a -01 revision of DPoP hopefully allowing folks enough =
time to read it before the interim meeting on Monday (apologies that it =
wasn't sooner but the edits took longer than expected or hoped). For =
ease of reference the changes in this revision are summarized below. =
There are, of course, still outstanding issues and discussion points =
that I hope to make some progress on during the interim meeting on =
Monday.
>=20
>    -01
>=20
>    *  Editorial updates
>    *  Attempt to more formally define the DPoP Authorization header
>       scheme
>    *  Define the 401/WWW-Authenticate challenge
>    *  Added "invalid_dpop_proof" error code for DPoP errors in token
>       request
>    *  Fixed up and added to the IANA section
>    *  Added "dpop_signing_alg_values_supported" authorization server
>       metadata
>    *  Moved the Acknowledgements into an Appendix and added a bunch of
>       names (best effort)
>=20
> ---------- Forwarded message ---------
> From: >
> Date: Fri, May 1, 2020 at 12:24 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
> To: Torsten Lodderstedt >, David Waite =
>, =
John Bradley >, Brian =
Campbell >, Daniel Fett >, Michael Jones >
>=20
>=20
>=20
> A new version of I-D, draft-ietf-oauth-dpop-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>=20
> Name:           draft-ietf-oauth-dpop
> Revision:       01
> Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the =
Application Layer (DPoP)
> Document date:  2020-05-01
> Group:          oauth
> Pages:          22
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt =

> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ =

> Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01 =

> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop =

> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01 =

>=20
> Abstract:
>    This document describes a mechanism for sender-constraining OAuth =
2.0
>    tokens via a proof-of-possession mechanism on the application =
level.
>    This mechanism allows for the detection of replay attacks with =
access
>    and refresh tokens.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org =
.
>=20
> The IETF Secretariat
>=20
>=20
>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_FF8A8D60-44AD-4553-BB37-516FE6AEC9A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Some =
review comments:

Section 1:
I think terms like =
=E2=80=9Crelatively simple=E2=80=9D are subjective and should be left =
out. I don=E2=80=99t think the machinery of JWS signature verification =
(and associated security issues) is necessarily simple at all.

=E2=80=9Cstronger =
methods =E2=80=A6 such as [RFC8705] or [token binding]=E2=80=9D
I would dispute that these are actually stronger methods in =
the context of an SPA, putting aside the usability issues. As has been =
discussed before, TLS is a shared context in a web browser - the same =
TLS connection will be reused for all requests, regardless of the origin =
they come from. The situation is better for cert-bound ATs because you =
need the CORS Access-Control-Allow-Credentials to be set to make a =
cross-origin request with a client certificate, but as I describe below =
there are also other attacks against TLS that don=E2=80=99t apply to =
DPoP (and would be a good reason to adopt DPoP). 

I think this section =
should also mention mobile use-cases, as IMO the case for DPoP is much =
stronger in those environments. Many of our customers are looking for a =
PoP solution for mobile and have rejected mTLS for various reasons =
(which have previously been discussed on this list, e.g. incompatible =
middleboxes). DPoP is potentially really nice for these environments as =
they often have a nice secure element available to store the private key =
and are much less susceptible to XSS and so on, but may still worry =
about a malicious RS. IoT applications may also be a use-case as =
requests are often relayed over multiple hops and different transport =
protocols, so TLS cannot be used for end-to-end security (although in =
that case you probably want a full request signing approach).

Section =
2:
I think the =E2=80=9CMain Objective=E2=80=9D in =
section 2 could be improved. The vast majority of the mechanisms =
described in the draft do nothing to address this main objective, and =
are in fact intended to prevent DPoP proof replay which is relegated to =
a =E2=80=9Csecondary objective=E2=80=9D in section 9. Only the =E2=80=9Cht=
u=E2=80=9D claim really has anything at all to do with the main =
objective. I think some of these secondary objectives, especially the =
anti-replay one, should be brought forward to section 2 to better =
justify what follows.

It has been mentioned several times on this list that an =
audience restriction in the AT would also solve this main objective, and =
the response has generally been that adding audience restrictions is =
hard in practice - e.g. due to the AS not knowing where the AT is =
intended to be used. I think it would be useful to explicitly add some =
discussion of this, and perhaps a comparison with things like resource =
indicators that presumably could solve at least some of the issues with =
audience restrictions.

I think there *are* significant advantages of DPoP that =
address real-world attacks that cannot be solved in any other way =
currently. For example, I was reading [1] recently about CRIME/BREACH =
attacks against CSRF tokens and it occurred to me that exactly the same =
kind of attack is a real threat to access tokens in a browser and that =
DPoP is an effective mitigation against it. To summarise, these attacks =
exploit vulnerabilities in TLS when combined with compression (either in =
TLS itself or HTTP compression) and can allow an attacker to steal =
bearer tokens or cookies after observing enough requests with the same =
token (and being able to influence some other content in the same =
request/response). One recommended mitigation is to randomize tokens so =
that they are different on every request, which thwarts the attack. =
Although DPoP doesn=E2=80=99t directly randomize the AT the AT is =
useless without a DPoP proof and a unique =E2=80=9Cjti=E2=80=9D claim =
ensures that the DPoP proof is randomized and so not recoverable through =
this attack. Given that BREACH is largely unmitigated in practice, due =
to the usefulness of compression, adding a description of this attack to =
the justification would IMO significantly improve the rationale for =
DPoP.

Section =
3:
The second bullet point of step (B) isn=E2=80=99t =
clear - is it implying that refresh tokens for confidential clients =
shouldn=E2=80=99t be DPoP-bound? Must not?

Step (C) implies that only =
JWT-structured ATs or token introspection are supported for =
communicating the public key. Presumably deployers are free to use =
another secure mechanism if they wish?

The last bullet point about requiring a =
DPoP proof for refresh tokens is ambiguous about what happens in the =
case of confidential clients if the refresh token is not DPoP-bound. Do =
they not supply a DPoP proof at all (and it reuses the original one), or =
must they supply a new one? Can they supply a *different* DPoP proof to =
e.g. rotate their key pair?

Section 4:
Maybe a forward reference to =
section 6 when mentioning the DPoP header field, as that=E2=80=99s where =
it is defined.

4.1:
I=E2=80=99m not keen about =
including the full =E2=80=9Cjwk=E2=80=9D in every DPoP proof. It never =
changes for the life of the AT and adds considerable overhead to the =
size of the proof. If the RS is using token introspection (with opaque =
ATs) then it would be much more efficient to return the JWK in the token =
introspection response and let the RS cache that. Alternatively the AS =
could publish the JWK under a URL on behalf of the client and include a =
=E2=80=9Cjku=E2=80=9D header instead.

In the last paragraph, is it worth =
explicitly calling out things like GraphQL as not suitable for DPoP due =
to the fact that they reuse the same URI and HTTP method for all =
requests?

4.2:
I feel like this section should =
contain a forward reference to section 6, otherwise it appears to =
suggest that verifying the signature and claims is sufficient - without =
the crucial step of ensuring that the JWK matches the actual access =
token. The potential for implementers to get this wrong is another =
reason to prefer not including the JWK directly in the DPoP proof but =
instead have it retrieved from the access token (either as a cnf or from =
token introspection). That makes it much harder to validate a proof that =
is unrelated to the AT.

Step 6 - HTTP methods are case-sensitive [2] so this check =
should also be.

Step 7 - It might be worth explicitly clarifying that =E2=80=9C=
HTTP URI=E2=80=9D means HTTPS.

Section 5:
Can we =
move the definition of the DPoP header syntax (currently in section 6) =
into its own section before here?

In the last paragraph delete =E2=80=9Cby =
a public client":

   When a DPoP-bound refresh token is used at =
the token endpoint by a
   public client, the AS MUST ensure that the DPoP proof contains the
   same public key as the one the refresh token is bound to.  The access
   token issued MUST be bound to the public key contained in the DPoP
   proof.


If a =
DPoP-bound RT is used then the AS should verify the DPoP proof matches =
the one bound to the RT regardless of which client presented it. =
(Otherwise a confidential client could steal RTs from a public client =
and circumvent the DPoP binding).

Is it worth explicitly mentioning at =
some point that the AS *shouldn=E2=80=99t* try to enforce any DPoP =
binding at the introspection endpoint? We=E2=80=99ve actually had bugs =
raised from people believing that we should enforce this for mTLS, not =
realising the chicken-and-egg situation that would create.

Section 6:
I may have missed it, but has there been any discussion of =
using a parameter on the Authorization header rather than an entirely =
separate header? For example:

Authorization: DPoP =
at=3D=E2=80=A6,proof=3D=E2=80=A6

Appendix A of RFC 7235 describes the =
use of token68 syntax for =E2=80=9Clegacy=E2=80=9D authentication =
schemes, so I assume the authparam syntax is preferred now and this =
would avoid adding another header (but it does mean that header might =
get very large if the AT is also a JWT, potentially exceeding size =
limits in servers/proxies).

(It=E2=80=99s also weird to explicitly define the syntax as =
token68 even though we know it's a JWT and will never contain some of =
those chars).

The example uses a JWT AT, which is needlessly confusing. I =
think using a short reference-based AT in this example would both reduce =
the size and also make clear that the DPoP proof goes in the DPoP header =
not the Authorization header.

Section 7:
As =
mentioned earlier, I=E2=80=99d prefer that the full JWK be included in =
the =E2=80=9Ccnf=E2=80=9D rather than a hash, but if we=E2=80=99re going =
to use a hash can we be explicit and use =E2=80=9Cjkt#S256=E2=80=9D =
please?

Section =
8:
Is the AS also allowed to return a =
WWW-Authenticate challenge with an algs attribute if the client sends a =
proof with an unsupported algorithm?

Section 9:
DPoP is =
not incompatible with TLS-based methods, and has advantages over them. I =
think the wording here should leave open the idea that you could =
actually use both.

9.1:
This would be a good place to =
mention BREACH as an example of how a DPoP proof (and AT) might leak, =
despite only being sent over a direct HTTPS channel. Note though that =
adding a random jti is an effective defence against this even if the =
server doesn=E2=80=99t check it.

9.2:
Maybe mention =
that clients should avoid reusing the same key for other JWTs =
too?

[1]: https://blog.hboeck.de/archives/900-Generating-CRIME-safe-CSRF-=
Tokens.html 
[2]: https://tools.ietf.org/html/rfc7230#section-3.1.1

Cheers,

Neil




On 1 May 2020, at 20:03, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> =
wrote:

I've pushed out a -01 revision of =
DPoP hopefully allowing folks enough time to read it before the interim =
meeting on Monday (apologies that it wasn't sooner but the edits took =
longer than expected or hoped). For ease of reference the changes in =
this revision are summarized below. There are, of course, still =
outstanding issues and discussion points that I hope to make some =
progress on during the interim meeting on Monday.
   -01

   *  Editorial updates
   *  Attempt to more formally define the DPoP =
Authorization header
      scheme
   *  Define the 401/WWW-Authenticate =
challenge
   *  Added "invalid_dpop_proof" =
error code for DPoP errors in token
      =
request
   *  Fixed up and added to the =
IANA section
   *  Added =
"dpop_signing_alg_values_supported" authorization server
      metadata
   * =
 Moved the Acknowledgements into an Appendix and added a bunch =
of
      names (best effort)

---------- Forwarded message =
---------
From: <internet-drafts@ietf..org>
Date: =
Fri, May 1, 2020 at 12:24 PM
Subject: New Version =
Notification for draft-ietf-oauth-dpop-01.txt
To: Torsten =
Lodderstedt <torsten@lodderstedt.net>, David =
Waite <david@alkaline-solutions.com>, John =
Bradley <ve7jtb@ve7jtb.com>, Brian Campbell <bcampbell@pingidentity.com>, Daniel Fett <mail@danielfett.de>, Michael Jones <mbj@microsoft.com>




A new version of I-D, draft-ietf-oauth-dpop-01.txt

has been successfully submitted by Brian Campbell and posted to the

IETF repository.



Name:           draft-ietf-oauth-dpop

Revision:       01

Title:          OAuth 2.0 Demonstration of =
Proof-of-Possession at the Application Layer (DPoP)

Document date:  2020-05-01

Group:          oauth

Pages:          22

URL:            https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.t=
xt

Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop=


Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01



Abstract:

   This document describes a mechanism for sender-constraining =
OAuth 2.0

   tokens via a proof-of-possession mechanism on the =
application level.

   This mechanism allows for the detection of replay attacks =
with access

   and refresh tokens.









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










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

=

--Apple-Mail=_FF8A8D60-44AD-4553-BB37-516FE6AEC9A7--


From nobody Mon May  4 08:38:52 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42213A0B21 for ; Mon,  4 May 2020 08:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hze_dbVs8TnI for ; Mon,  4 May 2020 08:38:48 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FA03A0AAC for ; Mon,  4 May 2020 08:38:44 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id s3so14270042eji.6 for ; Mon, 04 May 2020 08:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rbsGYYpKhjjEnU8k3qpUhQV5oj93dm/vaQVfGA1s6yY=; b=BsO1aCt1hhzsQ0JMDY/dcRJ3romgfvlZcKldzfLYzA3JYOiCEGtIID+Fna2UqhMe8V /suQ3Xgzk3beFs+KW/xvzvVt2/CHAVkm0Uyv3/nzsLthkF1eWGj2U1knRMcJBoUmE5UE KoANDRadxhjH3SJVtKyxVOMHTnTnnbjR0RPWg1Ra9kG1sRbcKM9rK20Q/HS/0aZeVAeE 3PGnJJnIK+Ha3sXgcWgGSpVZkJ2OYEx61BUFGb9znIB6MZl5lTyq6IyDK1srgFe5sS8t k+hgppioYRMIrh5PXria9XpD5j6HjdI0MQvwzBv1P7syf7dwtiq0TLeqbZ5Y2azyQBb+ UDZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rbsGYYpKhjjEnU8k3qpUhQV5oj93dm/vaQVfGA1s6yY=; b=ZcA4UOgETYmI9c6BIuOr6cxKWYD8znY90/pHp9NjxEYrQGRAODCXoJmb3oA0ZwT71r +3lFiSxx8zC3aTNAXc6ybqg5PeEo2kCLJVB0YVDFE1B304/fFRhG9PTZDLha2JkIypk4 pdq63I/JKavVEL7ST0q6Q4UW2zsZFhy3y8axuCYeXoMgl3aJKoRDqxB+tpJbfifLxDQT HQyFGA3qkqglhCvmra7qYMENxGCucNxWNGnnX5y4i/CLxysLztQK67ID+dRsI8jWVzgA XOWLWYzGPspb7sWCKR36KVJzS4XU96guViwRgvrLa1XUBV4HdYdy04WIiViFgqcOdwNw p7Gg==
X-Gm-Message-State: AGi0PuZeVtrC9CBYP23WYaGqgv/2fNJHxcQhXOGtTPpwR45csiG08dI9 nqLHdVQo/Ya29aHmw900n4QBNXY1BIjETD/84/U=
X-Google-Smtp-Source: APiQypJu8QQMFYn2H/imfPXo44J5cW3bM/LeyuveC5u8Uf67Sc54ECE8/X/okCnmfKhn54Q1leZDKaMG+H/q06tcC30=
X-Received: by 2002:a17:907:4272:: with SMTP id nq2mr3484407ejb.205.1588606722957;  Mon, 04 May 2020 08:38:42 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Jared Jennings 
Date: Mon, 4 May 2020 10:38:32 -0500
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000068e6b205a4d4533a"
Archived-At: 
Subject: Re: [OAUTH-WG] May 4th Interim Meeting Material
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 15:38:52 -0000

--00000000000068e6b205a4d4533a
Content-Type: text/plain; charset="UTF-8"

I'll be taking notes here
https://docs.google.com/document/d/1gVTUzkMFvS-XyrYBiXOqbUnl5zp5nlhZf57oKFY2bzc/edit?usp=sharing

Of course, Rifaat will publish once complete.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Sun, May 3, 2020 at 4:02 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Here is a link to the meeting material for tomorrow's meeting:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth
>
> Regards,
>  Rifaat & Hannes
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000068e6b205a4d4533a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'll be taking notes here=C2=A0https://docs.google.com/document/d/1gVTUzkMFvS-XyrYBiXOqbUnl5z=
p5nlhZf57oKFY2bzc/edit?usp=3Dsharing

Of course, Rifa=
at will publish once complete.

-Jared
Skype:jaredljennings
Signal:+=
1 816.730.9540
WhatsApp:=C2=A0+1 816.678.4152


On Sun, May 3, 2020 at 4:02 PM Rifaat Shekh-Yusef <<=
a href=3D"mailto:rifaat.ietf@gmail.com">rifaat.ietf@gmail.com> wrote=
:
All,

Here is a link to the meeting materia=
l for tomorrow's meeting:
https://data=
tracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth=C2=A0=C2=
=A0

Regards,
=C2=A0Rifaat & Hannes

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000068e6b205a4d4533a--


From nobody Mon May  4 10:24:42 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D351B3A0DA7 for ; Mon,  4 May 2020 10:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u2bM1oI3jbD for ; Mon,  4 May 2020 10:24:33 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274363A0D64 for ; Mon,  4 May 2020 10:24:33 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 2F3621855 for ; Mon,  4 May 2020 17:24:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588613071; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=cPfWYih2YGxn/p4kLhAPP2iKbCSdCNphSSL3unrhYgQ=; b=R+aRN7pTQlwn5w9H6fzJZP424fzmamOA4m8fNAv+9oBKK7BrISQFpy37BFDaBcrcpo4RjN NIyRhr7JzBXpAUvkud9ji6RrkXrr3D9AMC9+VTRa0zq3bbpWs8wRI44IA3NMNDvfk4OI3j TZKdQSd5KaaBaP1SArE2oIjOgDVDwrM=
To: oauth@ietf.org
From: Daniel Fett 
Message-ID: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de>
Date: Mon, 4 May 2020 19:24:30 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------05819584060CB9C3D19E3820"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588613071; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=cPfWYih2YGxn/p4kLhAPP2iKbCSdCNphSSL3unrhYgQ=; b=GiHvvkf3aTPJ3FWJshkz9xWgqIIFoWyWy+3E6W5/IIutmXey95eYw3/CAndxc8AVXy+rRi IKzd0xksTTBLNqeCFe63f+gqETN4Q3zTJRRkeetNepr2fAKInRMFe/9IAHmOcYDDC49527 Wdd72CRoLhYGNqrgSFHbyEib+9iyHro=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588613071; a=rsa-sha256; cv=none; b=M2FeHMpSwCoQ9vgC9BggYqjbgpMBksgTKzEDY5zLlfBl2HZWqtcApB3hwEMJ4gEN7TZjaq y97FxZr1R30f3G1p3rGoBZg11EWfC1sTREEnjRNQ820CK3yXsZ0JcRb0u95qYu+VOA57pS iXktBlVxMRCvvRAh8ksFP+UirtZD/Vo=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 17:24:41 -0000

This is a multi-part message in MIME format.
--------------05819584060CB9C3D19E3820
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi all,

as mentioned in the WG interim meeting, there are several ideas floating
around of what DPoP actually does.

In an attempt to clarify this, if have unfolded the use cases that I see
and written them down in the form of attacks that DPoP defends against:
https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

Can you come up with other attacks? Are the attacks shown relevant?

Cheers,
Daniel


--------------05819584060CB9C3D19E3820
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Hi all,

    
as mentioned in the WG interim meeting, there are several ideas
      floating around of what DPoP actually does.

    
In an attempt to clarify this, if have unfolded the use cases
      that I see and written them down in the form of attacks that DPoP
      defends against: 

      https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

    
Can you come up with other attacks? Are the attacks shown
      relevant?

    
Cheers,

      Daniel

    

  


--------------05819584060CB9C3D19E3820--


From nobody Mon May  4 10:35:52 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A73A0DC4 for ; Mon,  4 May 2020 10:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jWa3lNYRqL6 for ; Mon,  4 May 2020 10:35:49 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3953A0DC0 for ; Mon,  4 May 2020 10:34:58 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id AF6331902 for ; Mon,  4 May 2020 17:34:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588613696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=VKfHWKj2qRYvSwFR4Iji66ABOB0BznRwmQaMqvScMFk=; b=MiCUOhiQFUzS+Gi+xnEZyn9dmHcqKkLi4WbrauULrKBdmwQ7n+NEfJ/rVmk+wOPcBPQ/fT vbr8JFtim58LUet69Mvs/imqxpx98ZAO5gmPkQRs+6MFZTQ+aD6tgYtzMqywjKAW1vP1X2 H4+yxZtVkFRWkggrqkNZ2q44bxwc5vo=
To: oauth@ietf.org
From: Daniel Fett 
Message-ID: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de>
Date: Mon, 4 May 2020 19:34:56 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------ADF0DA7AF487FD566E4ED30D"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588613696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=VKfHWKj2qRYvSwFR4Iji66ABOB0BznRwmQaMqvScMFk=; b=ipJ07YpHZziZhTc6U31U0g+TgnvW7HJdt7qPlMSJ31xi6twUS4zAd9M6Tmv4ZcySUXfm6g 2Bovjv1Hv0FcD4qwFrujLCh29SuJGhlI4z1vqbQZjcvSEZSfFrd3Q0p8RSq/3frs1kjwbR 6SP3RWWzVwvrvlH8DnznwbqDDvw8Zus=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588613696; a=rsa-sha256; cv=none; b=iCgGgQHIuQp5uEUnBJ99cLH1UKYRg28Vc+qTMXZf/oahn5ERHUQxt9wbfxTwk5mY6HWWsd wS2sUw/kT0RLtg4/r3auKFbdlNuRBlk+W7KcJxLQzOPYTA0uYBKFE0/tWtiqvs4eVSsXqz b6BkCmNyskJ0P95H7r0mple4o+pbIwE=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: [OAUTH-WG] Mix-Up Revisited
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 17:35:51 -0000

This is a multi-part message in MIME format.
--------------ADF0DA7AF487FD566E4ED30D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi all,

to make substantiated recommendations for FAPI 2.0, the security
considerations for PAR, and the security BCP, I did another analysis on
the threats that arise from mix-up attacks. I was interested in
particular in two questions:

  * Does PAR help preventing mix-up attacks?
  * Do we need JARM to prevent mix-up attacks?

I wrote down several attack variants and configurations in the following
document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html

The key takeaways are:

 1. The security BCP needs to make clear that per-*AS* redirect URIs are
    only sufficient if OAuth Metadata is not used to resolve multiple
    issuers. Otherwise, per-*Issuer* redirect URIs or the iss parameter
    MUST be used.
 2. PAR-enabled authorization servers can protect the integrity better
    and protect against Mix-Up Attacks better if they ONLY accept PAR
    requests.
 3. We should emphasize the importance of the iss parameter (or issuer)
    in the authorization response. Maybe introduce this parameter in the
    security BCP or another document?
 4. Sender-constrained access tokens help against mix-up attacks when
    the access token is targeted.
 5. Sender-constraining the authorization code (PAR + PAR-DPoP?) might
    be worth looking into.

I would like to hear your thoughts!

-Daniel


--------------ADF0DA7AF487FD566E4ED30D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Hi all,

    
to make substantiated recommendations for FAPI 2.0, the security
      considerations for PAR, and the security BCP, I did another
      analysis on the threats that arise from mix-up attacks. I was
      interested in particular in two questions:

    
    
      
  • Does PAR help preventing mix-up attacks?
    • 
      
  • Do we need JARM to prevent mix-up attacks?
    • 
    

    
I wrote down several attack variants and configurations in the
      following document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html

    
The key takeaways are:

    
    
      
  1. The security BCP needs to make clear that per-AS
        redirect URIs are only sufficient if OAuth Metadata is not used
        to resolve multiple issuers. Otherwise, per-Issuer
        redirect URIs or the iss parameter MUST be used.
    2. 
      
  2. PAR-enabled authorization servers can protect the integrity
        better and protect against Mix-Up Attacks better if they ONLY
        accept PAR requests.
    3. 
      
  3. We should emphasize the importance of the iss parameter (or
        issuer) in the authorization response. Maybe introduce this
        parameter in the security BCP or another document?
    4. 
      
  4. Sender-constrained access tokens help against mix-up attacks
        when the access token is targeted.
    
      
    5. 
      
  5. Sender-constraining the authorization code (PAR + PAR-DPoP?)
        might be worth looking into.
    
      
    6. 
    

    
I would like to hear your thoughts!

    
-Daniel

    

  


--------------ADF0DA7AF487FD566E4ED30D--


From nobody Mon May  4 10:54:47 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEAA3A0B45 for ; Mon,  4 May 2020 10:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfaLbbXqy1wo for ; Mon,  4 May 2020 10:54:44 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821F53A0A79 for ; Mon,  4 May 2020 10:54:25 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id 188so477881wmc.2 for ; Mon, 04 May 2020 10:54:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HLz/AyLzwtJ+CxViPhU1VbbNdBcElhndFLAnbsI+NA8=; b=P+WDVBMnvOX2vUeh7NecYfdYjIQ23YHtTxEnrAhaNkENf5n6yYVHU8KbrPUzWJ3LtJ bFs5GE88XHwwS9T2VpinJz7whQxPUHtlFddZuG9PDMYHnI26u9D1DA5Gu+IE/HttTBUe O7/05OAqDK4fY5gb4IzrPbi2i4n19nSIaUbkU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HLz/AyLzwtJ+CxViPhU1VbbNdBcElhndFLAnbsI+NA8=; b=PGQxP6CyzcYc6xbn4DsJnZIXFNBxsJzKIbCsOA8dpLU16uy+jMAlap/dsB1/Bq7ZfG nwC2iRUOnTTnznNGpIYnwqLfwNAIGmEEePxdJWTIcvpV/h1qoHsldJObyBechRmuWxY8 t7cKkHh8ht/CqKDwZ4IAquC4lgKFvDwNQlFihT8DqzMBGWGZCcOhNUC7NxkyDWdDRBdz YzFsA6W3JB7sKjWEevUguUU5tpALXlLj9IhfX/q6HpOGhXrd6jFqpChFQL7FhzsYq3A6 9lKqXQmWCIqH2RurDqgEwjp+LZrJJttOyO5RAiq2C7SUWuMWK9+rOH28Fiqyk/LtVQig UJcw==
X-Gm-Message-State: AGi0PuamD9dKfMwK1tmozBRmNFw8cE4j1quvPu/nEgHJ8Y6PbDiTWZc7 eRrUFPOFAIon1/rArmnp5a0AGTsYxsM=
X-Google-Smtp-Source: APiQypIUA0eWZ1I6eufRTsXB/CgZ5hhbxLzy+g6rEdINcY7H3PA0MGecrZGpi/iTQTpn0MwI3yF3vg==
X-Received: by 2002:a1c:4989:: with SMTP id w131mr16767034wma.137.1588614863556;  Mon, 04 May 2020 10:54:23 -0700 (PDT)
Received: from [10.0.0.2] (193.207.159.143.dyn.plus.net. [143.159.207.193]) by smtp.gmail.com with ESMTPSA id s8sm16596738wrt.69.2020.05.04.10.54.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2020 10:54:22 -0700 (PDT)
From: Neil Madden 
Message-Id: <1427A993-02B5-4444-9FD5-0E62A32D2AF4@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_555F1817-8491-4854-B692-2808E93225DF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 4 May 2020 18:54:21 +0100
In-Reply-To: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de>
Cc: oauth@ietf.org
To: Daniel Fett 
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 17:54:46 -0000

--Apple-Mail=_555F1817-8491-4854-B692-2808E93225DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I mentioned another one in my recent email - BREACH attacks against HTTP =
compression being used to steal access tokens in transit.

There=E2=80=99s a variant of the online XSS attacks in which the =
attacker just proxies requests through the victim=E2=80=99s browser =
(https://beefproject.com ) rather than =
exfiltrating tokens/proofs. You can protect against exfiltration attacks =
by e.g. token binding the DPoP proofs and/or access token, or storing =
the access token in a HttpOnly cookie (gasp!). You can protect against =
exfiltrating post-dated DPoP proofs by storing the private key in a =
separate origin loaded in an iframe that you use postMessage to ask for =
proof tokens so the attacker is not in control of those claims. Nothing =
really protects against an attacker proxying requests through your =
browser, so this is purely post-compromise recovery rather than an =
actual defence against XSS.

=E2=80=94 Neil

> On 4 May 2020, at 18:24, Daniel Fett  wrote:
>=20
> Hi all,
>=20
> as mentioned in the WG interim meeting, there are several ideas =
floating around of what DPoP actually does.
>=20
> In an attempt to clarify this, if have unfolded the use cases that I =
see and written them down in the form of attacks that DPoP defends =
against:=20
> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html =

> Can you come up with other attacks? Are the attacks shown relevant?
>=20
> Cheers,
> Daniel
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_555F1817-8491-4854-B692-2808E93225DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
mentioned another one in my recent email - BREACH attacks against HTTP =
compression being used to steal access tokens in transit.

There=E2=80=99s a =
variant of the online XSS attacks in which the attacker just proxies =
requests through the victim=E2=80=99s browser (https://beefproject.com) =
rather than exfiltrating tokens/proofs. You can protect against =
exfiltration attacks by e.g. token binding the DPoP proofs and/or access =
token, or storing the access token in a HttpOnly cookie (gasp!). You can =
protect against exfiltrating post-dated DPoP proofs by storing the =
private key in a separate origin loaded in an iframe that you use =
postMessage to ask for proof tokens so the attacker is not in control of =
those claims. Nothing really protects against an attacker proxying =
requests through your browser, so this is purely post-compromise =
recovery rather than an actual defence against XSS.

=E2=80=94 Neil

On 4 May 2020, at 18:24, Daniel =
Fett <fett@danielfett.de> wrote:


 =20

    
 =20
  
Hi all,
as mentioned in =
the WG interim meeting, there are several ideas
      floating around of what DPoP actually does.
In an =
attempt to clarify this, if have unfolded the use cases
      that I see and written them down in the form of attacks that DPoP
      defends against: 

      https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Mode=
l.html
Can you come up with other attacks? Are the =
attacks shown
      relevant?
Cheers,

      Daniel

    

  


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

=

--Apple-Mail=_555F1817-8491-4854-B692-2808E93225DF--


From nobody Mon May  4 11:06:47 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2A3A0E6F for ; Mon,  4 May 2020 11:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuTbVUusW4ff for ; Mon,  4 May 2020 11:06:44 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906853A0E6D for ; Mon,  4 May 2020 11:06:43 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d38 with ME id ai6g2200E4FMSmm03i6gQR; Mon, 04 May 2020 20:06:41 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 04 May 2020 20:06:41 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de>
From: Denis 
Message-ID: 
Date: Mon, 4 May 2020 20:06:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de>
Content-Type: multipart/alternative; boundary="------------910133FB3FC63ABD3C055B89"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 18:06:46 -0000

This is a multi-part message in MIME format.
--------------910133FB3FC63ABD3C055B89
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Daniel,

Yes indeed. For another attack, please see my email sent to the list on 
01/05/2020 at 10:47 (Paris time).
The subject was: DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks.

When the JWT does not contain a sufficient number of attributes that 
would allow to identify the user,
the collaborative user can transmit it to anybody else, without the risk 
to be detected by the RS.  E.g. it
only contains the age of the user and a membership to a large group of 
people.

When the JWT contains attributes that uniquely allow to identify the 
collaborative user, then the other client
will be in a position to impersonate the collaborative user. Some users 
may not accept to be impersonated
by anybody and thus will only be collaborative with some trusted friends.

This collaborative attack would be much simpler to accomplish than the 
four types of attacks that have been described.
As soon as a software solution would be available to perform this 
collaborative attack, everybody would be able to use it.

Denis

> Hi all,
>
> as mentioned in the WG interim meeting, there are several ideas 
> floating around of what DPoP actually does.
>
> In an attempt to clarify this, if have unfolded the use cases that I 
> see and written them down in the form of attacks that DPoP defends 
> against:
> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
>
> Can you come up with other attacks? Are the attacks shown relevant?
>
> Cheers,
> Daniel
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------910133FB3FC63ABD3C055B89
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Daniel,

    


    

    
Yes indeed. For another attack, please
      see my email sent to the list on 01/05/2020 at 10:47 (Paris time).

    

    
The subject was: DPoP
      draft-ietf-oauth-dpop-0 Client collaborative attacks.

    
When the JWT does not contain a sufficient number of attributes
      that would allow to identify the user,

      the collaborative user can transmit it to anybody else, without
      the risk to be detected by the RS.  E.g. it 

      only contains the age of the user and a membership to a large
      group of people.

    

    
When the JWT contains attributes that uniquely allow to identify
      the collaborative user, then the other client 

      will be in a position to impersonate the collaborative user. Some
      users may not accept to be impersonated 

      by anybody and thus will only be collaborative with some trusted
      friends.

    
This collaborative attack would be much simpler to accomplish
      than the four types of attacks that have been described.

      As soon as a software solution would be available to perform this
      collaborative attack, everybody would be able to use it.

    

    
Denis

    

      
      
Hi all,

      
as mentioned in the WG interim meeting, there are several ideas
        floating around of what DPoP actually does.

      
In an attempt to clarify this, if have unfolded the use cases
        that I see and written them down in the form of attacks that
        DPoP defends against: 

        https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

      
Can you come up with other attacks? Are the attacks shown
        relevant?

      
Cheers,

        Daniel

      

      

      

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


    

    


    

  


--------------910133FB3FC63ABD3C055B89--


From nobody Mon May  4 12:03:40 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE403A1330 for ; Mon,  4 May 2020 12:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63NMDtUGACjt for ; Mon,  4 May 2020 12:03:30 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1623A12A2 for ; Mon,  4 May 2020 12:02:52 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 302E1198C for ; Mon,  4 May 2020 19:02:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588618971; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IyeM+95AuEt8B+p4D5cPfXjArwjOe1xgy6Nb7VkC3zU=; b=jAIK29N27nkllqDspxfd88PjDNgbIJdzj1nOp6vGe8yUXgU+FiLne5jAUNOG962zaMS0WW ZE/YoZWKdvDiXKtKo8I66/vG0Jwwmf+6Il9Mm9Ufq5bOVt6u1YwOSbUCsxmdUf72uV29xB nLlVJQjpifNRtwhxB1oP9xqXQA8E6XA=
To: oauth@ietf.org
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de> 
From: Daniel Fett 
Message-ID: <04440508-a4e7-9cab-288b-2414c72e19ac@danielfett.de>
Date: Mon, 4 May 2020 21:02:50 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B83E8DF30727BFDEF28FD628"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588618971; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IyeM+95AuEt8B+p4D5cPfXjArwjOe1xgy6Nb7VkC3zU=; b=IERea38NBp92QcOSPCB8f9ZBIXqmkqxpAezoE+ZTBhHGksc+RDy5FflRH3E2s0lajad19y b2faLmXudP24RKPrCwZ51OjAT2sYS2/13M548dlEcBBMz/kDF+/w8BqjahKkrwqugLAgIE R9Eg2NngEK+PtZnjrOnxeYwunuRvfwM=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588618971; a=rsa-sha256; cv=none; b=X9Y3zZA00ak8ePAxuPUHtI6vg5ME/HbljtKwTudaNDb/u4zvf4aLR/n//ao34UQqfRm0Y+ 0gluEQ7610EuKpQc3h6z1+kyZv5GbpjaY0oepSB4N9TcZxNA2lBbLR1cWXFMjdvyKzTz0w mknjBaMr+G3xTOKD8oq+W9s81HV3akM=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 19:03:39 -0000

This is a multi-part message in MIME format.
--------------B83E8DF30727BFDEF28FD628
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi Denis,

We discussed these kinds of collusion attacks at great length previously
on this list. My views on them have not changed.

Am 04.05.20 um 20:06 schrieb Denis:
> As soon as a software solution would be available to perform this
> collaborative attack, everybody would be able to use it.

Teamviewer is sufficient and widely available.

-Daniel


> Denis
>
>> Hi all,
>>
>> as mentioned in the WG interim meeting, there are several ideas
>> floating around of what DPoP actually does.
>>
>> In an attempt to clarify this, if have unfolded the use cases that I
>> see and written them down in the form of attacks that DPoP defends
>> against:
>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
>>
>> Can you come up with other attacks? Are the attacks shown relevant?
>>
>> Cheers,
>> Daniel
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------B83E8DF30727BFDEF28FD628
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Denis,

    


    

    
We discussed these kinds of collusion
      attacks at great length previously on this list. My views on them
      have not changed.

    


    

    
Am 04.05.20 um 20:06 schrieb Denis:

    

    

      
      As soon as a software solution would be available to perform this
      collaborative attack, everybody would be able to use it.

    

    
Teamviewer is sufficient and widely available.

    
-Daniel

    


    

    

      
 

      
Denis

      

        
        
Hi all,

        
as mentioned in the WG interim meeting, there are several
          ideas floating around of what DPoP actually does.

        
In an attempt to clarify this, if have unfolded the use cases
          that I see and written them down in the form of attacks that
          DPoP defends against: 

          https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

        
Can you come up with other attacks? Are the attacks shown
          relevant?

        
Cheers,

          Daniel

        

        

        

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


      

      


      

      

      

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


    

    


    

  


--------------B83E8DF30727BFDEF28FD628--


From nobody Mon May  4 12:16:34 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CDF3A0E9D for ; Mon,  4 May 2020 12:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmsZ9Ea9gaAJ for ; Mon,  4 May 2020 12:16:32 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6BF3A0DDA for ; Mon,  4 May 2020 12:16:26 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id EBC7A1912; Mon,  4 May 2020 19:16:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588619784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=czc230T5Eb8Py5RpWmeT3pVXQwkbcBdpPic6Vlgpwjw=; b=q0FSsnnMjcqrwk9cqWOB2w7ZdKkGfnv/hv2Z1N0JDwvRvFBLixS1gCS019Ed+EamKBMcY9 F3VwJBY945fIpXsgwJsRnEDPDl5HaJcZxhZ3ey5NdYlYpKQRUOx9ncokMqOjDdW71SjSCH qA50ompcVgIdzeZxWL26m7lhnV0npco=
To: Neil Madden 
Cc: oauth@ietf.org
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de> <1427A993-02B5-4444-9FD5-0E62A32D2AF4@forgerock.com>
From: Daniel Fett 
Message-ID: 
Date: Mon, 4 May 2020 21:16:23 +0200
MIME-Version: 1.0
In-Reply-To: <1427A993-02B5-4444-9FD5-0E62A32D2AF4@forgerock.com>
Content-Type: multipart/alternative; boundary="------------0AED41F837B4E69DE8ADBC7D"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588619784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=czc230T5Eb8Py5RpWmeT3pVXQwkbcBdpPic6Vlgpwjw=; b=bhz31hvDlqjegFcdJN27AKkKDwnIK5gDUbi+mtebPoy/Be9Ea8xnkWq9Mx0T/B4w4tSw// BHWrAkA7fiuXzdQSQnIK4EBvjWvQCAGxW5ql8PFC+YCMGA2A6gKDhRP/K1vw4+EWysBRxx 42il7LJu8S/m1IMZThUHeXRuWxtLv/w=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588619784; a=rsa-sha256; cv=none; b=B5FU9tvabeNO2aIjVB/VCSwnMinBfbkR84vZgIqCxbD1Ngz3SuwQ9IGqz9jvLpBFEn1XT/ n21yTbAr/AzzFMRCrjdc71HF0Oj+iGh/uf3E3n+WHrC1mAc8BKFz4UFek+pf/ruM8YqjDd PhmEaGLOqXcSSd/YRT/103QOrfd1dwo=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 19:16:34 -0000

This is a multi-part message in MIME format.
--------------0AED41F837B4E69DE8ADBC7D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Am 04.05.20 um 19:54 schrieb Neil Madden:
> I mentioned another one in my recent email - BREACH attacks against
> HTTP compression being used to steal access tokens in transit.
Excellent point, I added that one.
>
> There’s a variant of the online XSS attacks in which the attacker just
> proxies requests through the victim’s browser

That was the attack that should have been described under "Online XSS"
in the first place. I somehow got confused along the way. Exfiltration
of precomputed values is definitely /not/ "Online XSS".

> (https://beefproject.com) rather than exfiltrating tokens/proofs.

As a sidenote: BeEF is not really XSS but requires a full browser
compromise.

Thanks for the feedback!

-Daniel


> You can protect against exfiltration attacks by e.g. token binding the
> DPoP proofs and/or access token, or storing the access token in a
> HttpOnly cookie (gasp!). You can protect against exfiltrating
> post-dated DPoP proofs by storing the private key in a separate origin
> loaded in an iframe that you use postMessage to ask for proof tokens
> so the attacker is not in control of those claims. Nothing really
> protects against an attacker proxying requests through your browser,
> so this is purely post-compromise recovery rather than an actual
> defence against XSS.
>
> — Neil
>
>> On 4 May 2020, at 18:24, Daniel Fett > > wrote:
>>
>> Hi all,
>>
>> as mentioned in the WG interim meeting, there are several ideas
>> floating around of what DPoP actually does.
>>
>> In an attempt to clarify this, if have unfolded the use cases that I
>> see and written them down in the form of attacks that DPoP defends
>> against:
>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
>>
>> Can you come up with other attacks? Are the attacks shown relevant?
>>
>> Cheers,
>> Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>


--------------0AED41F837B4E69DE8ADBC7D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Am 04.05.20 um 19:54 schrieb Neil
      Madden:

    

    

      
      I mentioned another one in my recent email - BREACH attacks
      against HTTP compression being used to steal access tokens in
      transit.

    Excellent point, I added that one.

    

      


      

      
There’s a variant of the online XSS attacks in which
        the attacker just proxies requests through the victim’s browser
      

    

    
That was the attack that should have been described under "Online
      XSS" in the first place. I somehow got confused along the way.
      Exfiltration of precomputed values is definitely not
      "Online XSS".

    

      
(https://beefproject.com) rather
        than exfiltrating tokens/proofs. 

    

    
As a sidenote: BeEF is not really XSS but requires a full browser
      compromise.

    
Thanks for the feedback!

    
-Daniel

    


    

    

      
You can protect against exfiltration attacks by e.g.
        token binding the DPoP proofs and/or access token, or storing
        the access token in a HttpOnly cookie (gasp!). You can protect
        against exfiltrating post-dated DPoP proofs by storing the
        private key in a separate origin loaded in an iframe that you
        use postMessage to ask for proof tokens so the attacker is not
        in control of those claims. Nothing really protects against an
        attacker proxying requests through your browser, so this is
        purely post-compromise recovery rather than an actual defence
        against XSS.

      


      

      
— Neil

      


      

      

        

          

            
On 4 May 2020, at 18:24, Daniel Fett <fett@danielfett.de> wrote:

            

            

              
              

                
Hi all,

                
as mentioned in the WG interim meeting,
                  there are several ideas floating around of what DPoP
                  actually does.

                
In an attempt to clarify this, if have
                  unfolded the use cases that I see and written them
                  down in the form of attacks that DPoP defends against:
                  

                  https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

                
Can you come up with other attacks? Are the
                  attacks shown relevant?

                
Cheers,

                  Daniel

                

              

              _______________________________________________

              OAuth mailing list

              OAuth@ietf.org

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

            

          

        

        

      

    

    


    

  


--------------0AED41F837B4E69DE8ADBC7D--


From nobody Mon May  4 12:28:07 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726F03A092B for ; Mon,  4 May 2020 12:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=fmNcmFUA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vZey5kEp
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARJCt2xuXJyS for ; Mon,  4 May 2020 12:28:03 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF953A0F55 for ; Mon,  4 May 2020 12:27:46 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 051D44C5; Mon,  4 May 2020 15:27:44 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 04 May 2020 15:27:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=6Zt0zyExtQfhPQM8QNM9/FWfDa8yUobo0Ir0gNSVjmk=; b=fmNcmFUAhumy /2PLVYbTNKCDAmpOvJfnkHFwzuz1LgWirRDfpGhKXiCZLgZykRHSMF5BUaWoMPeS eYbjknWxdxRIo9ioZC/k+42ZVg/pgfg9rCuxlBUPQX36HQtZSfqKZAviD+N/EBBb wkr9stMUZnOYEIsCjIl8e30NlkfE4MxNlBCbCPYTE1QK7wjsBpyORmY4W11JWDZm xjG5K/6u6MyvPq9+NYNncoeL10PLXM5C9OE9rsDSOoT9TT/8PGlToh/63xD1w7Cc NnAm1Hdi6bSrpyEByxtGngyiKz0i46p74lYwA5zeoLJbdD5lWaRqVTkkAhwpgzSh 2bf0eLde+w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=6Zt0zy ExtQfhPQM8QNM9/FWfDa8yUobo0Ir0gNSVjmk=; b=vZey5kEp81TKoPXnVKM6K0 Dd59D6+jJ7v5ofrOgGPoIEaH1CsR3AlxQ7TGWHlXVFZ4PV0pi/c84PDv3b9vEu13 35YmyyhsXU2dZ/iBKm5DMIYZ5aeemJY3Q98x7wmYgOFXSyOJycXRQjNYoZqgqkxS B+S2BGvhiCEvItQpL3cEdG2k/curBXISQmUPGOilNC8/hbc4Duly6BPAsJrb8MSh WXUZb2Ck8a5o/tmP9xq+ESRTeUBZUPDFcGBmAh9Um6T2q3Z4oKGbiGj2WSZfd7JC 2rqtay23Y1N52/5ODGXaoYrirjjshyMCjJk5LKa2qW4BRRPjsVtdCxCaUHgLfbzw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeggdduvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhephffktgggufffjgfvfhfo segrtdhmrehhtdejnecuhfhrohhmpefrhhhilhhiphhpvgcuffgvucfthigtkhcuoehphh hilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtohhmqeenucgg tffrrghtthgvrhhnpeeugffgledtieelveelkefhgfdthfelfffgkeeukefhtefhjeeike ffjeejfeejleenucffohhmrghinhepsggvvghfphhrohhjvggtthdrtghomhdpphhrrghg mhgrthhitgifvggsshgvtghurhhithihrdgtohhmpdhhthhtphhonhhlhigtohhokhhivg hgrghsphdrhihouhdpghhithhhuhgsrdhiohdpihgvthhfrdhorhhgnecukfhppeelgedr vddvhedrhedrudeivdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithih rdgtohhm
X-ME-Proxy:    
Received: from imacvanphilippe.localdomain (94-225-5-162.access.telenet.be [94.225.5.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F9273280069; Mon,  4 May 2020 15:27:43 -0400 (EDT)
From: Philippe De Ryck 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C3242332-B3DE-4B28-B143-95E69A5ADFD2"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 4 May 2020 21:27:42 +0200
In-Reply-To: 
Cc: Neil Madden , oauth@ietf.org
To: Daniel Fett 
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de> <1427A993-02B5-4444-9FD5-0E62A32D2AF4@forgerock.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 19:28:06 -0000

--Apple-Mail=_C3242332-B3DE-4B28-B143-95E69A5ADFD2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


>> (https://beefproject.com ) rather than =
exfiltrating tokens/proofs.
> As a sidenote: BeEF is not really XSS but requires a full browser =
compromise.
>=20

No, it=E2=80=99s not. The hook for BeEF is a single JS file, containing =
a wide variety of attack payloads that can be launched from the command =
and control center. You can combine BeEF with Metasploit to leverage an =
XSS to exploit browser vulnerabilities and break out.

FYI, the name for the attack where the attacker proxies calls through =
the user=E2=80=99s browser is known as Session Riding.=20

Just keep in mind that once an attacker has an XSS foothold, it is =
extremely hard to prevent abuse. The only barrier that cannot be broken =
(in a secure browser) is the Same Origin Policy. Keeping tokens and =
metadata in a separate environment (e.g., iframe, worker, =E2=80=A6) is =
effective to keep them out of reach. However, once the app =
=E2=80=9Cextracts=E2=80=9D data from such a context, the same problem =
arises. By rewriting JS functions, the attacker can extract tokens from =
deep within an SDK, as I discuss here: =
https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html =


Kind regards

Philippe
> Thanks for the feedback!
>=20
> -Daniel
>=20
>=20
>=20
>> You can protect against exfiltration attacks by e.g. token binding =
the DPoP proofs and/or access token, or storing the access token in a =
HttpOnly cookie (gasp!). You can protect against exfiltrating post-dated =
DPoP proofs by storing the private key in a separate origin loaded in an =
iframe that you use postMessage to ask for proof tokens so the attacker =
is not in control of those claims. Nothing really protects against an =
attacker proxying requests through your browser, so this is purely =
post-compromise recovery rather than an actual defence against XSS.
>>=20
>> =E2=80=94 Neil
>>=20
>>> On 4 May 2020, at 18:24, Daniel Fett > wrote:
>>>=20
>>> Hi all,
>>>=20
>>> as mentioned in the WG interim meeting, there are several ideas =
floating around of what DPoP actually does.
>>>=20
>>> In an attempt to clarify this, if have unfolded the use cases that I =
see and written them down in the form of attacks that DPoP defends =
against:=20
>>> =
https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html =

>>> Can you come up with other attacks? Are the attacks shown relevant?
>>>=20
>>> Cheers,
>>> Daniel
>>>=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=_C3242332-B3DE-4B28-B143-95E69A5ADFD2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



    

      
(https://beefproject.com) rather
        than exfiltrating tokens/proofs. 

    
As a sidenote: BeEF is not really XSS but =
requires a full browser
      compromise.

No, it=E2=80=99s not. The hook for BeEF =
is a single JS file, containing a wide variety of attack payloads that =
can be launched from the command and control center. You can combine =
BeEF with Metasploit to leverage an XSS to exploit browser =
vulnerabilities and break out.

FYI, the name for the attack where the =
attacker proxies calls through the user=E2=80=99s browser is known as =
Session Riding. 

Just keep in mind that once an attacker has an XSS foothold, =
it is extremely hard to prevent abuse. The only barrier that cannot be =
broken (in a secure browser) is the Same Origin Policy. Keeping tokens =
and metadata in a separate environment (e.g., iframe, worker, =E2=80=A6) =
is effective to keep them out of reach. However, once the app =
=E2=80=9Cextracts=E2=80=9D data from such a context, the same problem =
arises. By rewriting JS functions, the attacker can extract tokens from =
deep within an SDK, as I discuss here: https://pragmaticwebsecurity.com/articles/oauthoidc/localstorag=
e-xss.html

Kind regards

Philippe
Thanks for the feedback!
-Daniel


    

    

      
You can protect against exfiltration attacks by =
e.g.
        token binding the DPoP proofs and/or access token, or storing
        the access token in a HttpOnly cookie (gasp!). You can protect
        against exfiltrating post-dated DPoP proofs by storing the
        private key in a separate origin loaded in an iframe that you
        use postMessage to ask for proof tokens so the attacker is not
        in control of those claims. Nothing really protects against an
        attacker proxying requests through your browser, so this is
        purely post-compromise recovery rather than an actual defence
        against XSS.

      


      

      
=E2=80=94 Neil

      


      

      

        

          

            
On 4 May 2020, at 18:24, Daniel Fett <fett@danielfett.de> wrote:

            

            

              
              
Hi all,
as =
mentioned in the WG interim meeting,
                  there are several ideas floating around of what DPoP
                  actually does.
In an attempt to =
clarify this, if have
                  unfolded the use cases that I see and written them
                  down in the form of attacks that DPoP defends against:
                  

                  https://danielfett.github.io/notes/oauth/DPoP%20A=
ttacker%20Model.html
Can you come up with other =
attacks? Are the
                  attacks shown relevant?
Cheers,

                  Daniel

                

              

              _______________________________________________

              OAuth mailing 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=_C3242332-B3DE-4B28-B143-95E69A5ADFD2--


From nobody Mon May  4 12:45:37 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B180D3A0F86 for ; Mon,  4 May 2020 12:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWLWHgfZD7mR for ; Mon,  4 May 2020 12:45:32 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB663A0F85 for ; Mon,  4 May 2020 12:44:54 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id BB45117F2; Mon,  4 May 2020 19:44:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588621493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=umU0u6YyG2EHaDVAFz4BB/Hjo1Lkti4C5a2T6V18doc=; b=aEaZste3o5iMV3OPxnZVXc4YKsZjN+2j99EaTmWIQX6DFMRxefr6BV5DaqUXgDUAVDw2o+ TglMxiUQ+EIvWDGZMjo6KqD4jTVCJdDGf1tuOmnlRkt5ttMiiJwxo9fz0roi2353lNL4iR mU9LUQ44DVZmhPvvW2Oz2N7+CVMD51A=
To: Philippe De Ryck 
Cc: Neil Madden , oauth@ietf.org
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de> <1427A993-02B5-4444-9FD5-0E62A32D2AF4@forgerock.com>  
From: Daniel Fett 
Message-ID: 
Date: Mon, 4 May 2020 21:44:52 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DC2C5C71BBD01E5462F6A64F"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588621493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=umU0u6YyG2EHaDVAFz4BB/Hjo1Lkti4C5a2T6V18doc=; b=AL/8hRLdtPa10op/y68iJKvBrxxZFKvxVM6v3Tbfu+5Bs9+dzlNWXgPXObM/lZTHkn0nj/ n8OHllElGlZYbpYaTNtDu7u5+b4lZCVTvFdamwcs7j2eXuvSPFlx2EHJFLrXwreCkMXI9s V6Sk50JTUamMzU3/4wZhWZozcgCBprc=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588621493; a=rsa-sha256; cv=none; b=Vgk+T4a+zETlmt4WNpOYydTjJY4kSXFMGZnlS6q9tKg4zJquUJEPWVM2P/gClxwrRWLX/L yJj8qmh/Z7ZdLN3fj0rCBCuTjihc75yujU/nC6s9jo09UIt79HTo6b7PqXYD8z8yro/9BG sSfHhW7v/lasoHuy7VHslFV8xZxcDOM=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 19:45:35 -0000

This is a multi-part message in MIME format.
--------------DC2C5C71BBD01E5462F6A64F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
>
>>> (https://beefproject.com ) rather than
>>> exfiltrating tokens/proofs.
>>
>> As a sidenote: BeEF is not really XSS but requires a full browser
>> compromise.
>>
>
> No, it’s not. The hook for BeEF is a single JS file, containing a wide
> variety of attack payloads that can be launched from the command and
> control center. You can combine BeEF with Metasploit to leverage an
> XSS to exploit browser vulnerabilities and break out.
I shall stand corrected!
>
> Just keep in mind that once an attacker has an XSS foothold, it is
> extremely hard to prevent abuse. The only barrier that cannot be
> broken (in a secure browser) is the Same Origin Policy. Keeping tokens
> and metadata in a separate environment (e.g., iframe, worker, …) is
> effective to keep them out of reach. However, once the app “extracts”
> data from such a context, the same problem arises.

Compartmentalization within an origin is as old a problem as it is
mostly unsolved, indeed. That is why I would not further differentiate
in case the browser is online and the client's script is compromised,
but instead assume that the attacker can then forge arbitrary requests
using the token.

-Daniel


--------------DC2C5C71BBD01E5462F6A64F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Am 04.05.20 um 21:27 schrieb Philippe
      De Ryck:

    

    

      
      

      

        

          

            

              
(https://beefproject.com)
                rather than exfiltrating tokens/proofs. 

            

            
As a sidenote: BeEF is not really XSS but
              requires a full browser compromise.

          

        

        


        

        
No, it’s not. The hook for BeEF is a single JS
          file, containing a wide variety of attack payloads that can be
          launched from the command and control center. You can combine
          BeEF with Metasploit to leverage an XSS to exploit browser
          vulnerabilities and break out.

      

    

    I shall stand corrected!

    

      

        


        

        
Just keep in mind that once an attacker has an XSS
          foothold, it is extremely hard to prevent abuse. The only
          barrier that cannot be broken (in a secure browser) is the
          Same Origin Policy. Keeping tokens and metadata in a separate
          environment (e.g., iframe, worker, …) is effective to keep
          them out of reach. However, once the app “extracts” data from
          such a context, the same problem arises. 

        

      

    

    
Compartmentalization within an origin is as old a problem as it
      is mostly unsolved, indeed. That is why I would not further
      differentiate in case the browser is online and the client's
      script is compromised, but instead assume that the attacker can
      then forge arbitrary requests using the token.

    
-Daniel

    

  


--------------DC2C5C71BBD01E5462F6A64F--


From nobody Mon May  4 12:48:57 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B00D3A0FA5 for ; Mon,  4 May 2020 12:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=KRmiEg/U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nHydzCN/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMGuEmWxF1uC for ; Mon,  4 May 2020 12:48:53 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453273A0FA6 for ; Mon,  4 May 2020 12:48:53 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id A28E8497; Mon,  4 May 2020 15:48:51 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 04 May 2020 15:48:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=pis63t9nEg408oCyTnV9i0DMupxv8n10vbuCH0u12vg=; b=KRmiEg/UvX3b IKq+H1PRaKK5jX5I+r0VxcJMZyErhoyEFUIT9NP4XZhoZTjqpv85ZoZuryILn8Zx itrS0PPLHlVo+bAOIrAVY/rmxfuhcja6k8QGgzl8UVqAh0/N3rvdTi7NW72Ljoc+ M7YA5J44utlJfLSudBKFLPiWaWnrc0LMTwVmM37NvGMiUVnKO5dY9EBdLnLrU5NC PF32nRsRjGTPWSesT88PapqgaAgFTiwtcpJ2yGACizHaPtZJxILqHfrVPdH9oneY HmwrDlmSIDiOw6a/IHXTT3ce+hhLIKpqK+itwwfm0XFVGLYtaahJZLP2zqwU5hcW InBlE3GRfg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pis63t 9nEg408oCyTnV9i0DMupxv8n10vbuCH0u12vg=; b=nHydzCN/NyCOaZQnPK5eIn 00DT2gVpMEGapvESAp1Ea/5aitqx1GGXkHbQydbI1+NyTlHM49z+4ZBmxdW6U62F mIJ11tiLpQ6Pp0hTW2KQgJEYUy7kphu41ipC+svVuZ6ZBy+0ilfVa35d4lBG7WeJ zJyGjdrrofE9RP7MdibNx/aKmdOxluv30wvrVNGR9v75Z0TtrK9AYGFfCLj1jTIx 219l1GoOGASVfPD5rOslyoA5tPj85APZIvaBrM9tPuvMfFEbGvEWQ/Vi34c8dzBV Pd4GE0nLUJRsHgmVLvXu6j8LymoHK1wnPm/6pywBm4q535Nal/0QFx27XWRODAiA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeggddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpefrhhhilhhi phhpvgcuffgvucfthigtkhcuoehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggssh gvtghurhhithihrdgtohhmqeenucggtffrrghtthgvrhhnpefghfeljeegffffieevieel hfekieetleduueelteejheffgeelueeuvdeugffhteenucffohhmrghinhepsggvvghfph hrohhjvggtthdrtghomhenucfkphepleegrddvvdehrdehrdduiedvnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpphgvsehprh grghhmrghtihgtfigvsghsvggtuhhrihhthidrtghomh
X-ME-Proxy:    
Received: from imacvanphilippe.localdomain (94-225-5-162.access.telenet.be [94.225.5.162]) by mail.messagingengine.com (Postfix) with ESMTPA id F35A13066029; Mon,  4 May 2020 15:48:49 -0400 (EDT)
From: Philippe De Ryck 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_15C73CFF-5FDF-4CA7-A298-363C934DAD07"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 4 May 2020 21:48:49 +0200
In-Reply-To: 
Cc: Neil Madden , oauth@ietf.org
To: Daniel Fett 
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de> <1427A993-02B5-4444-9FD5-0E62A32D2AF4@forgerock.com>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 19:48:55 -0000

--Apple-Mail=_15C73CFF-5FDF-4CA7-A298-363C934DAD07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 4 May 2020, at 21:44, Daniel Fett  wrote:
>=20
> Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
>>=20
>>>> (https://beefproject.com ) rather than =
exfiltrating tokens/proofs.
>>> As a sidenote: BeEF is not really XSS but requires a full browser =
compromise.
>>>=20
>>=20
>> No, it=E2=80=99s not. The hook for BeEF is a single JS file, =
containing a wide variety of attack payloads that can be launched from =
the command and control center. You can combine BeEF with Metasploit to =
leverage an XSS to exploit browser vulnerabilities and break out.
> I shall stand corrected!
>>=20
>> Just keep in mind that once an attacker has an XSS foothold, it is =
extremely hard to prevent abuse. The only barrier that cannot be broken =
(in a secure browser) is the Same Origin Policy. Keeping tokens and =
metadata in a separate environment (e.g., iframe, worker, =E2=80=A6) is =
effective to keep them out of reach. However, once the app =
=E2=80=9Cextracts=E2=80=9D data from such a context, the same problem =
arises.=20
> Compartmentalization within an origin is as old a problem as it is =
mostly unsolved, indeed. That is why I would not further differentiate =
in case the browser is online and the client's script is compromised, =
but instead assume that the attacker can then forge arbitrary requests =
using the token.
>=20
I agree on that assumption. The moment malicious script executes, it=E2=80=
=99s game over, regardless of the specifics on whether a token can be =
extracted or not. Even with isolation, an attacker would be able to =
trick the isolated context in making requests as a confused deputy.

Philippe=

--Apple-Mail=_15C73CFF-5FDF-4CA7-A298-363C934DAD07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On =
4 May 2020, at 21:44, Daniel Fett <fett@danielfett.de> =
wrote:


 =20
    
 =20
  

    
Am 04.05.20 um 21:27 schrieb Philippe
      De Ryck:

    

    

      
      

      

        

          

            

              
(https://beefproject.com)
                rather than exfiltrating tokens/proofs. 

            
As a sidenote: BeEF is not really =
XSS but
              requires a full browser compromise.

          

        

        


        

        
No, it=E2=80=99s not. The hook for BeEF is a =
single JS
          file, containing a wide variety of attack payloads that can be
          launched from the command and control center. You can combine
          BeEF with Metasploit to leverage an XSS to exploit browser
          vulnerabilities and break out.

      

    

    I shall stand corrected!

    

      

        


        

        
Just keep in mind that once an attacker has an =
XSS
          foothold, it is extremely hard to prevent abuse. The only
          barrier that cannot be broken (in a secure browser) is the
          Same Origin Policy. Keeping tokens and metadata in a separate
          environment (e.g., iframe, worker, =E2=80=A6) is effective to =
keep
          them out of reach. However, once the app =E2=80=9Cextracts=E2=80=
=9D data from
          such a context, the same problem arises. 

        

      

    
Compartmentalization within an origin is =
as old a problem as it
      is mostly unsolved, indeed. That is why I would not further
      differentiate in case the browser is online and the client's
      script is compromised, but instead assume that the attacker can
      then forge arbitrary requests using the =
token.
I agree on that assumption. The =
moment malicious script executes, it=E2=80=99s game over, regardless of =
the specifics on whether a token can be extracted or not. Even with =
isolation, an attacker would be able to trick the isolated context in =
making requests as a confused deputy.

Philippe
=

--Apple-Mail=_15C73CFF-5FDF-4CA7-A298-363C934DAD07--


From nobody Mon May  4 12:58:52 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDB73A0FBD for ; Mon,  4 May 2020 12:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T4j7wqi0j6g for ; Mon,  4 May 2020 12:58:48 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28D73A0FC8 for ; Mon,  4 May 2020 12:58:46 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id k6so13721429iob.3 for ; Mon, 04 May 2020 12:58:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dj7K2+Zo98NHmCAjYoX6T3XCSd+wTXyZbO9eX9JdmyE=; b=BZvKKcd6m0hYw7FMqjbpru3K0/EqAdVKZAfAoiZdk233IAUsw4Xcz24NgWECZfAai/ SQoEg3UljgxNsevUzDT8r4rJ5Zuug8+imuWL8bmqetVT1RC7rKS1dlAae+j/iVa4S9Ti jeq+5myFDSw7+0lfJOQjjkMgFcb7VJJzFGE28pORilsN6LGestS8o7vPKhFWEjr9oGHz O9uXtpNN4rVV9soeIR64TeTdjR9x9kh2e8SZcjK2hAMQTiQWw92uhyWJkmlIsCkISZA4 +css84rasj/2KWkUOLtrv+IYZ6zS1kwi0mxnQ8pRx1BOpLKXf7pLAOf74lzIdj7ej85A X27g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dj7K2+Zo98NHmCAjYoX6T3XCSd+wTXyZbO9eX9JdmyE=; b=a2o06JwbVw0X7QNHXIGglDE1W39rOcuoovmBOqeuXpPu6c8nMzrAxBrX9Jo+xIbHJc YLI8SH7pm/A1W7mVIk9yrlOjkWK/qzzje2smKjtbx480J4EU7KX33kHF2sWiBLhdoz6r uy1RBH/61/jmK1y7GwHS8+H1Nm+kYPOnDWzY4HDoWQqMMYYry2sQU+ZXk+yKUQ5VMyTE Ty+8B29UNW8Yh+iYf/YQzJqNCrWohXd+xZwQCQ8ThnPTCOevAUeRaNaf3b9NIEzg//7O PTpPzplUiVqKFSxjqRy0hJIZKlsUaPamoF3WvhgptjiuAw3ipAdCrPjTYBZr5PRUMJfW DSNw==
X-Gm-Message-State: AGi0Pubb0L5iCfuKCZUnqyO1obBQLsiQ1buQu0VtbzWz7qak2c7MjK50 LJ3BD7fYYoc5ESU4Zs1/LPjgtgO48kUU1+cBAamuoQ35reWERw==
X-Google-Smtp-Source: APiQypJSvpS0+kMCWq1AjTQzjWtRDchhJcXu1XZLv01TWy9nZUyxAen2+XuKL0L7ZWuxmO4EL1GF8Uv0NB6gzITDyUY=
X-Received: by 2002:a05:6602:15ca:: with SMTP id f10mr16998427iow.51.1588622325642;  Mon, 04 May 2020 12:58:45 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Mon, 4 May 2020 15:58:34 -0400
Message-ID: 
To: Jared Jennings 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000066fa6605a4d7f594"
Archived-At: 
Subject: Re: [OAUTH-WG] May 4th Interim Meeting Material
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 19:58:50 -0000

--00000000000066fa6605a4d7f594
Content-Type: text/plain; charset="UTF-8"

All,

You can find the meeting minutes and the link to the recording on the
following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-07/materials/minutes-interim-2020-oauth-07-202005041200


Thanks to *Jared Jennings* for taking these notes.

Regards,
 Rifaat


On Mon, May 4, 2020 at 11:38 AM Jared Jennings 
wrote:

> I'll be taking notes here
> https://docs.google.com/document/d/1gVTUzkMFvS-XyrYBiXOqbUnl5zp5nlhZf57oKFY2bzc/edit?usp=sharing
>
> Of course, Rifaat will publish once complete.
>
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: +1 816.678.4152
>
>
> On Sun, May 3, 2020 at 4:02 PM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> Here is a link to the meeting material for tomorrow's meeting:
>> https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth
>>
>>
>> Regards,
>>  Rifaat & Hannes
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--00000000000066fa6605a4d7f594
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

You can find the meeting minutes a=
nd the link to the recording on the following link:



On Mon, May 4, 2020 at 11:38 AM Jared Jennings <jaredljennings@gmail.com> =
wrote:
I'll be taking notes here=C2=A0https://docs.google.com/document/d/1gVTUzkMFvS-XyrYB=
iXOqbUnl5zp5nlhZf57oKFY2bzc/edit?usp=3Dsharing

Of co=
urse, Rifaat will publish once complete.

<=
div dir=3D"ltr">
-Jared
Skype:jaredljen=
nings
Signal:+1 816.730.9540
WhatsApp:=C2=A0+1 816.678.=
4152


On Sun, May 3, 2020 at 4:02 PM =
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

=

Here is a link to the meeting material for tomorrow's meeting:https://datatracker.ietf.org/meeting/interim-=
2020-oauth-07/session/oauth=C2=A0=C2=A0

Regards,=

=C2=A0Rifaat & Hannes

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






--00000000000066fa6605a4d7f594--


From nobody Mon May  4 13:49:23 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5C3A1053 for ; Mon,  4 May 2020 13:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e_NBszmKs1Q for ; Mon,  4 May 2020 13:49:17 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751FD3A1029 for ; Mon,  4 May 2020 13:48:52 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id b2so11146009ljp.4 for ; Mon, 04 May 2020 13:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=58uDT9h1qi4UrledwE/uCat67r02OhjFOBXtfIWHTC4=; b=QQw4c7Ng8hrho5aRlAwzdZRuFLWXNYEqkK0lUD8FYOMuK6aU5mrNP3CQNipYtDuz8l MggAy9ExiwHhXqPZNvZEVopDA2D1D1do6wQfwfBQ1kzg38/cBGeDa51ko2jloont8leI 9XdP9cdfaJMK/NVHYD0EJruBapu5NPioQTOlvPjdK8+2TGVdjx5oaXOW90lUOc8LdvJ5 yTd+mza5BJkUaByqUaWgHovuGQd0mCQvxtmDCpdDlq+VDzp1upME6u7LzxTY0B4ZElHR toQq4T52rGpqpwUZWrw3So2hdTJHu0iyMwVv1h1iYVzQ+E1RZ5w6j4vBdBY6qg9hlP0H Wf+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=58uDT9h1qi4UrledwE/uCat67r02OhjFOBXtfIWHTC4=; b=mw3GYr8XV0m+QT5jG3vnqaTSjF7adBiRyuQ1PJnduvq8tmFjY8Nvl+dw3wJXAm4nH0 B4cCWLLvhrS+5P6HFLyGihMWlbw6MmRv9s2xHcEiaMHy+r4B9ZPWnwazRRmEbRfli67w yhd/RvrqYYyghpsCXfi9OX7z1qyEH9HV4+vud9Qo0724WeGhm8F2BJ1RzxbxvsAzDByH DofeJKf462HOuEYiOjrv42uMYvBwMaK65uGYfE1GareNB8UZI4YA3ZwDmW7lvrur4+sy cRAE1YeaMkYYLH4C+Yo2FrUiDRYbBZ/esj+pBL8tYZrM+401CUjyjKWNxoGQ112Xmhdt YHVA==
X-Gm-Message-State: AGi0PuYuE80IQm+0PoKuUwJdzB8gChQ6qxfnfId/KEEyaM2vtBnOGONJ 4kjx0MZh1c7YcmMadlW3tBQEEI1A15Q0akNCvEYU/rYidisMfNW3vwmKao4Dl4udO/6/GjqutdA CACm8sQkiJfT3vSvwTC8=
X-Google-Smtp-Source: APiQypJdaE17gMcdgtkotggyWcyl4bgF63QSfQvGhV3gBHPJNP1X/nBMsLNAUgmxgnsVG7aDpKhAoqiyXJestgTQznQ=
X-Received: by 2002:a2e:9455:: with SMTP id o21mr11537389ljh.245.1588625330412;  Mon, 04 May 2020 13:48:50 -0700 (PDT)
MIME-Version: 1.0
References: <158835743733.12112.7484502726888997082@ietfa.amsl.com>  
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 4 May 2020 14:48:24 -0600
Message-ID: 
To: William Denniss 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000080387105a4d8a8a1"
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 May 2020 20:49:20 -0000

--00000000000080387105a4d8a8a1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks William and nice to see you pop up on the list again. Your
perspective and feedback is appreciated (and missed a little bit these
days). Attempts to respond to things that seemed to warrant a response are
inline below.

On Sun, May 3, 2020 at 5:54 PM William Denniss  wrote:

> Hi Brian, et. al,
>
> I reviewed the document. Overall I think the concept is clearly
> communicated, both the need, and how it is implemented. It was easy to
> read, and concise. Great work!
>
> Some comments and nits:
>
> =C2=A7 1:
> (nit) "DPoP" should be defined on first use in the body of the document,
> in my opinion.
>

Yeah, you're probably right. Will make that change.



> =C2=A7 3:
>
> I don't follow this why the sentence "For confidential clients, refresh
> tokens are bound to the "client_id", which is more flexible than binding =
it
> to a particular public key." belongs in this explanation of the diagram. =
Is
> it indicating that DPoP is not required for confidential clients? If the
> sentence was deleted / moved elsewhere in the doc, would it alter the
> meaning of the diagram?
>
> I wonder if the diagram would be simpler with less optionality (e.g.
> public / confidential separated into 2 diagrams, if they behave
> differently), or maybe just kept as 1 simple diagram, with any optionalit=
y
> described later. Generally I think these kind of overview diagrams (which
> are extremely helpful, and now I must go add one to my own draft) are bes=
t
> if they give an overview of the protocol without trying to document the
> entire specification, or justify why different decisions are made.
>

So the intended intent of the document is that refresh tokens be DPoP bound
only when issued to public clients. RFC6749 already requires that an AS
bind refresh tokens to the client to which they were issued and that
confidential clients (those having established authentication credentials
with the AS) authenticate to the AS when presenting a refresh token. Thus,
refresh tokens issued to confidential clients are already
sender-constrained to the client and its credentials.

Although the binding of refresh tokens only applies to public clients, it
seemed like a relevant enough piece of the overall DPoP picture to warrant
inclusion in the intro. And it doesn't change the overall flow so a
separate diagram would look the same :/

I take your point, however, and can work towards the "simple diagram, with
any optionality described later" type approach. Which, I think might just
end up being some tightening up of the language in the intro and better
explaining and justifying things later in the document.



=C2=A7 4.1 figure 2
>
> (nit) When showing a decoded JWT with the signature dropped, I think it's
> a good idea to first present the full encoded JWT. Someone who is new to
> JWT may not realize that this data has a signature (or even that it is
> encoded at all), since it was dropped already, while showing the
> before/after can make this clear. Not essential, I just think it would he=
lp
> readers. Having this also sets the scene for later when encoded JWTs are
> used in example request headers.
>

I'm always trying to find the right balance of including enough to be
useful but not too darn much in examples. In this case though I think you
might be right and that first presenting the full encoded JWT would be
useful. But also not overdoing it.


=C2=A7 4.1, below figure 2:
>
> Regarding "Note: To keep DPoP simple to implement, only the HTTP method
> and URI
>    are signed in DPoP proofs."
>
> I found this confusing as the entire JWT is signed, and the signature
> covers the whole JWT and not just those 2 claims. I get that since the JW=
T
> only meaningfully contains the HTTP method and URI that the statement is
> effectively true, but I would rephrase. Something along the lines of:
>
> "Of the HTTP headers in the request, only the HTTP method and URI are
> included in the DPoP JWT, and therefore only these 2 headers of the reque=
st
> are covered by the DPoP proof"
>

Agree this could be phrased in a better way.




> (nit) I would also drop the "To keep DPoP simple to implement" here, and
> maybe move any discussion about the design trade-offs to the security
> considerations (9.4).
>

Makes sense.


>
> =C2=A7 5
>
> (nit) Expand "AS" on first use (or better: just say "authorization server=
"
> and skip the acronym in this case, as "AS" is insider lingo IMO)
>

Will just stick with "authorization server" here and throughout.



> =C2=A7 5
>
> Regarding "If a refresh token is issued to a public client"...
>
> What about when it's issued to the confidential client? I think when
> specific behavior is documented for one client type, it's probably good t=
o
> at least mention how the other types behave.
>
> I think this could be clarified here. In fact, I wonder if the text I
> highlighted earlier from =C2=A7 3 might belong here.
>

Yeah, I think some of the more wordy bits from =C2=A7 3 would be better mov=
ed
here. That could keep the intro context more concise and, to your point,
cover what happens here for both types of clients.


> =C2=A7 8
>
> (nit) Suggest moving to an Appendix
>

Admittedly it doesn't flow particularly well here but it's still a
normative part of the spec so I don't think it belongs in an Appendix.


>
> =C2=A7 9.1
>
> (nit) "up to a few seconds", I would just say "e.g. a few seconds in the
> future". Seems odd to specify an upper bound on a non-exact number.
>

Aggree.


>
> =C2=A7 9.4
>
> " DPoP does not ensure the integrity of the payload or headers of
>    requests.  The signature of DPoP proofs only contains the HTTP URI
>    and method, but not, for example, the message body or other request
>    headers."
>
> Again, I find this an awkward phrase, "the signature of the DPoP proofs
> only contains the HTTP URI and method", and I think it' better to talk
> about the JWT only containing these claims, and the signature therefore
> only signing those claims. Also, (nit) does a proof "contain" something, =
or
> more accurately cover/sign something?
>

I'll work on the phrasing here too.


>
> William
>
>
>
>
> On Fri, May 1, 2020 at 12:04 PM Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
>
>> I've pushed out a -01 revision of DPoP hopefully allowing folks enough
>> time to read it before the interim meeting on Monday (apologies that it
>> wasn't sooner but the edits took longer than expected or hoped). For eas=
e
>> of reference the changes in this revision are summarized below. There ar=
e,
>> of course, still outstanding issues and discussion points that I hope to
>> make some progress on during the interim meeting on Monday.
>>
>>    -01
>>
>>    *  Editorial updates
>>    *  Attempt to more formally define the DPoP Authorization header
>>       scheme
>>    *  Define the 401/WWW-Authenticate challenge
>>    *  Added "invalid_dpop_proof" error code for DPoP errors in token
>>       request
>>    *  Fixed up and added to the IANA section
>>    *  Added "dpop_signing_alg_values_supported" authorization server
>>       metadata
>>    *  Moved the Acknowledgements into an Appendix and added a bunch of
>>       names (best effort)
>>
>> ---------- Forwarded message ---------
>> From: 
>> Date: Fri, May 1, 2020 at 12:24 PM
>> Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
>> To: Torsten Lodderstedt , David Waite <
>> david@alkaline-solutions.com>, John Bradley , Brian
>> Campbell , Daniel Fett ,
>> Michael Jones 
>>
>>
>>
>> A new version of I-D, draft-ietf-oauth-dpop-01.txt
>> has been successfully submitted by Brian Campbell and posted to the
>> IETF repository.
>>
>> Name:           draft-ietf-oauth-dpop
>> Revision:       01
>> Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the
>> Application Layer (DPoP)
>> Document date:  2020-05-01
>> Group:          oauth
>> Pages:          22
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01
>>
>> Abstract:
>>    This document describes a mechanism for sender-constraining OAuth 2.0
>>    tokens via a proof-of-possession mechanism on the application level.
>>    This mechanism allows for the detection of replay attacks with access
>>    and refresh tokens.
>>
>>
>>
>>
>> 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
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited...  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and any f=
ile
>> attachments from your computer. Thank you.*
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

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

--00000000000080387105a4d8a8a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks William and nice to see you pop up on the list=
 again. Your perspective and feedback is appreciated (and missed a little b=
it these days). Attempts to respond to things that seemed to warrant a resp=
onse are inline below. 

On Sun, May 3, 2020 at 5:54 PM William Denniss &=
lt;wdenniss=3D40google.com@dmarc.ietf.org> wrote:
Hi Brian, et. al,

I reviewed the document. Overall I think the concept=
 is clearly communicated, both the need, and how it is implemented. It was =
easy to read, and concise. Great work!

Some commen=
ts and nits:

=C2=A7 1:
(nit) "D=
PoP" should be defined on first use in the body of the document, in my=
 opinion.

Yeah, you're prob=
ably right. Will make that change.=C2=A0 

=C2=
=A0
=C2=A7 3:

I don't follow this=
 why the sentence "For confidential clients, refresh tokens are bound =
to the "client_id", which is more flexible than binding it to a p=
articular public key." belongs in this explanation of the diagram. Is =
it indicating that DPoP is not required for confidential clients? If the se=
ntence was deleted / moved elsewhere in the doc, would it alter the meaning=
 of the diagram?

I wonder if the diagram would be =
simpler with less optionality (e.g. public / confidential separated into 2 =
diagrams, if they behave differently), or maybe just kept as 1 simple diagr=
am, with any optionality described later. Generally I think these kind of o=
verview diagrams (which are extremely helpful, and now I must go add one to=
 my own draft) are best if they give an overview of the protocol without tr=
ying to document the entire specification, or justify why different decisio=
ns are made.

So the intended in=
tent of the document is that refresh tokens be DPoP bound only when issued =
to public clients. RFC6749 already requires that an AS bind refresh tokens =
to the client to which they were issued and that confidential clients (thos=
e having established authentication credentials with the AS) authenticate t=
o the AS when presenting a refresh token. Thus, refresh tokens issued to co=
nfidential clients are already sender-constrained to the client and its cre=
dentials. 

Although the binding of refresh tok=
ens only applies to public clients, it seemed like a relevant enough piece =
of the overall DPoP picture to warrant inclusion in the intro. And it doesn=
't change the overall flow so a separate diagram would look the same :/=
 

I take your point, however, and can work tow=
ards the "simple diagram, with any optionality described later" t=
ype approach. Which, I think might just end up being some tightening up of =
the language in the intro and better explaining and justifying things later=
 in the document.



=C2=A7 4.1 figure=
 2

(nit) When showing a decoded JWT with the s=
ignature dropped, I think it's a good idea to first present the full en=
coded JWT. Someone who is new to JWT may not realize that this data has a s=
ignature (or even that it is encoded at all), since it was dropped already,=
 while showing the before/after can make this clear. Not essential, I just =
think it would help readers. Having this also sets the scene for later when=
 encoded JWTs are used in example request headers.
=


I'm always trying to find the right balance of incl=
uding enough to be useful but not too darn much in examples. In this case t=
hough I think you might be right and that first presenting the full encoded=
 JWT would be useful. But also not overdoing it.
=C2=A0
=


=C2=A7=C2=A04.1, below figure 2:

Reg=
arding "Note: To keep DPoP simple to implement, only the HTTP method a=
nd URI
=C2=A0 =C2=A0are signed in DPoP proofs."

I found this confusing as the entire JWT is signed, and the signature cov=
ers the whole JWT and not just those 2 claims. I get that since the JWT onl=
y meaningfully contains the HTTP method and URI that the statement is effec=
tively true, but I would rephrase. Something along the lines of:
=

"Of the HTTP headers in the request, only the HTTP meth=
od and URI are included in the DPoP JWT, and therefore only these 2 headers=
 of the request are covered by the DPoP proof"

Agree this could be phrased in a better way.
=

=C2=A0

=C2=A0
(nit) I would also=
 drop the "To keep DPoP simple to implement" here, and maybe move=
 any discussion about the design trade-offs to the security considerations =
(9.4).

Makes sense. 
<=
div>=C2=A0

=C2=A7 5

(nit) Ex=
pand "AS" on first use (or better: just say "authorization s=
erver" and skip the acronym in this case, as "AS" is insider=
 lingo IMO)

Will just stick wit=
h "authorization server" here and throughout. 

=

=C2=A0
=C2=A7 5

Regard=
ing "If a refresh token is issued to a public client"...

What about when it's issued to the confidential client=
? I think when specific behavior is documented for one client type, it'=
s probably good to at least mention how the other types behave.
<=
br>
I think this could be clarified here. In fact, I wonder if th=
e text I highlighted earlier from =C2=A7 3 might belong here.

Yeah, I think some of the more wordy bits fr=
om =C2=A7 3 would be better moved here. That could keep the intro context m=
ore concise and, to your point, cover what happens here for both types of c=
lients. 
=C2=A0
=C2=A7 8

(nit=
) Suggest moving to an Appendix

Admittedly it doesn't flow particularly well here but it's still a=
 normative part of the spec so I don't think it belongs in an Appendix.=
 
=C2=A0

=C2=A7 9.1

=

(nit) "up to a few seconds", I would just say "e.g. a f=
ew seconds in the future". Seems odd to specify an upper bound on a no=
n-exact number.

Aggree. 
=C2=A0

=C2=A7 9.4

&qu=
ot; DPoP does not ensure the integrity of the payload or headers of
=C2=
=A0 =C2=A0requests.=C2=A0 The signature of DPoP proofs only contains the HT=
TP URI
=C2=A0 =C2=A0and method, but not, for example, the message body o=
r other request
=C2=A0 =C2=A0headers."

Again, I find this an awkward phrase, "the signature of the DPoP proo=
fs only contains the HTTP URI and method", and I think it' better =
to talk about the JWT only containing these claims, and the signature there=
fore only signing those claims. Also, (nit) does a proof "contain"=
; something, or more accurately cover/sign something?

I'll work on the phrasing here too. 
=C2=A0

William




On Fri, May 1, 2020 at 12:04 PM Brian Campbell <bcampbell=3D<=
a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin=
gidentity.com@dmarc.ietf.org> wrote:
I've pushed out a -01=
 revision of DPoP hopefully allowing folks enough time to read it before th=
e interim meeting on Monday (apologies that it wasn't sooner but the ed=
its took longer than expected or hoped). For ease of reference the changes =
in this revision are summarized below. There are, of course, still outstand=
ing issues and discussion points that I hope to make some progress on durin=
g the interim meeting on Monday.

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

=C2=A0 =C2=A0* =C2=A0Editorial updates
=C2=A0 =C2=A0* =C2=
=A0Attempt to more formally define the DPoP Authorization header
=C2=A0 =
=C2=A0 =C2=A0 scheme
=C2=A0 =C2=A0* =C2=A0Define the 401/WWW-Authenticat=
e challenge
=C2=A0 =C2=A0* =C2=A0Added "invalid_dpop_proof" er=
ror code for DPoP errors in token
=C2=A0 =C2=A0 =C2=A0 request
=C2=A0=
 =C2=A0* =C2=A0Fixed up and added to the IANA section
=C2=A0 =C2=A0* =C2=
=A0Added "dpop_signing_alg_values_supported" authorization server=

=C2=A0 =C2=A0 =C2=A0 metadata
=C2=A0 =C2=A0* =C2=A0Moved the Acknowl=
edgements into an Appendix and added a bunch of
=C2=A0 =C2=A0 =C2=A0 nam=
es (best effort)

---------- Forwarded message ---------
From: <internet-drafts@ietf..org>
Date: Fri, May 1, 2020 at 1=
2:24 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-01.t=
xt
To: Torsten Lodderstedt <torsten@lodderstedt.net>, David Waite <david@alkaline-=
solutions.com>, John Bradley <ve7jtb@ve7jtb.com>, Brian Campbell <bcampbell@pingiden=
tity.com>, Daniel Fett <mail@danielfett.de>, Michael Jones <mbj@microsoft.com>




A new version of I-D, draft-ietf-oauth-dpop-01.txt

has been successfully submitted by Brian Campbell and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dpop

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Demonstration of Proof-o=
f-Possession at the Application Layer (DPoP)

Document date:=C2=A0 2020-05-01

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.t=
xt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http=
s://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool=
s.ietf.org/html/draft-ietf-oauth-dpop-01

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https=
://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01



Abstract:

=C2=A0 =C2=A0This document describes a mechanism for sender-constraining OA=
uth 2.0

=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application =
level.

=C2=A0 =C2=A0This mechanism allows for the detection of replay attacks with=
 access

=C2=A0 =C2=A0and refresh tokens.









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










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

OAuth mailing list

OAuth@ietf.org

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








<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000080387105a4d8a8a1--


From nobody Tue May  5 05:30:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11D83A0062 for ; Tue,  5 May 2020 05:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIWY_oICd0PF for ; Tue,  5 May 2020 05:30:21 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990063A005F for ; Tue,  5 May 2020 05:30:21 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id x2so810514ilp.13 for ; Tue, 05 May 2020 05:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=Tr9mrFaBQu8NgCwVZVtHgbe1ne23bp49D9kFfUl82z0=; b=K3QyQ13doMJRWwdv3dgFbkR/pEs5go4bt6c8q1oEDJDx2mrX1VxUTCISockMbRXsMb zFP+/s94cuZCC/C7+cit4cEz7Ywp72nJo2mCly0t53YopSbxLCJtFtYKRQLnKwjEgqiU xVWmllSdRJDmbATWcgs1GE1QpsmRhZQV+lLeSVD7dcIP5njH33QVryjAVvbUpX9hnMHK 0u9svzsBb7wEMk3i4NOMb5rrDqMv3RNj004KfLJrxOauyGqbJb/7tt/K9g2iCe14VMFi XH0igmWUkGecxFnaWi0KlAzZAbvthSxlXg4IsJtlAMfJMgXFPmtNbDYl15ohhHvCInKu 7fcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Tr9mrFaBQu8NgCwVZVtHgbe1ne23bp49D9kFfUl82z0=; b=Tu5FaH5cbq+p8+uh5dnLP1+WaXBcTSN39Ss3A4fIPBiTlKk3ZuLvrWGhSeCAFxKjUg cc4hgyNZiDDR+MN1YPtUadrUIB0Di5OADpOLgpsV5HTVUUDKpSeyFPdKGTYahetqOCb5 8wFzi7LdqhnYQNt4qGMu7mkO6adBbL5TAXErFaeyRGU7YBbaHtb+dIaKlyZjt0ssVnsD d503V46myZPF1/lw50M5mwd7b/vH6G8V7bHPG0c/TO4VLCi3ZKlnPEYmu7pUMLywLxbN 00XfsVOloUjOQJMUH54dof5/NuHOnc1IOoqtBBky/oVgoIwH5A1yV0buy4nAZVRINZsu 2WAw==
X-Gm-Message-State: AGi0PubtHtBp90LeyLt0Il51ylREYk89wz8CghJu5juws6qxktWtw3sg hSjAzyFi5MMJ9+rwp31loz1WH9xf3sXaqUVPCOcLDQb+vQs=
X-Google-Smtp-Source: APiQypLOsYR1m2dgv59n/iXBD+oqj7pgcaAAv5wrA7SQXyvqZTzvYIDPSZEGXqTdQ0PHlsbqsvidmexZj/+QmiHQnwM=
X-Received: by 2002:a92:d3c5:: with SMTP id c5mr3359022ilh.73.1588681820596; Tue, 05 May 2020 05:30:20 -0700 (PDT)
MIME-Version: 1.0
References: <158857581528.28405.17372040856513106617@ietfa.amsl.com>
In-Reply-To: <158857581528.28405.17372040856513106617@ietfa.amsl.com>
From: Rifaat Shekh-Yusef 
Date: Tue, 5 May 2020 08:30:08 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000093ef0c05a4e5cfe2"
Archived-At: 
Subject: [OAUTH-WG] Fwd: Reminder: Survey on planning for possible online IETF meetings
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 12:30:24 -0000

--00000000000093ef0c05a4e5cfe2
Content-Type: text/plain; charset="UTF-8"

All,

Please take sometime to complete the survey below to help with the planning
for the coming, most likely virtual, IETF meetings.

Regards,
 Rifaat



---------- Forwarded message ---------
From: IETF Executive Director 
Date: Mon, May 4, 2020 at 3:04 AM
Subject: Reminder: Survey on planning for possible online IETF meetings
To: IETF Announcement List 


This is a reminder that we need the IETF community to help us plan for the
possibility that one or more upcoming IETF meetings in 2020 and possibly
2021 may not be able to go ahead in person.  You can help us with this by
filling out the following survey:

        https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to
complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that
you explicitly provide.

Thank you in advance for your help.

-- 
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--00000000000093ef0c05a4e5cfe2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

Please take sometime to complete t=
he survey=C2=A0below to help with the planning for the coming, most likely =
virtual, IETF meetings.

Regards,
=C2=A0R=
ifaat



---------- Forwarded message ---------
Fro=
m: IETF Executive Director<=
/strong> <exec-director@ietf.org>
Date: Mon, May 4,=
 2020 at 3:04 AM
Subject: Reminder: Survey on planning for possible onli=
ne IETF meetings
To: IETF Announcement List <ietf-announce@ietf.org>


This is a reminder that we need the IETF community to help us plan=
 for the possibility that one or more upcoming IETF meetings in 2020 and po=
ssibly 2021 may not be able to go ahead in person.=C2=A0 You can help us wi=
th this by filling out the following survey: 



=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.surveymonkey.com/r/532=
8FFJ



So far we have 114 responses and we would ideally like 500 or more.



The survey contains the following pages and will take 15-20 minutes to comp=
lete:



1. Welcome

2. Online IETF 107 and the subsequent virtual interims

3. Replacing a cancelled in-person meeting

4. Online meeting format and timezone

5. Replicating humming

6. Replicating the hallway environment

7. Fees

8. Thanks and anything else



We run the survey in anonymous mode which means that we only see data that =
you explicitly provide.



Thank you in advance for your help.



-- 

Alissa Cooper, IETF Chair

Jay Daley, IETF Executive Director

Colin Perkins, IRTF Chair



_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announ=
ce




--00000000000093ef0c05a4e5cfe2--


From nobody Tue May  5 08:15:18 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDF23A0768 for ; Tue,  5 May 2020 08:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA6zDc51gxkA for ; Tue,  5 May 2020 08:15:13 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E75B3A03F2 for ; Tue,  5 May 2020 08:15:12 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d07 with ME id b3F9220084FMSmm033F9mW; Tue, 05 May 2020 17:15:10 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 05 May 2020 17:15:10 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: <9ee75fc4-c134-1a36-1fa3-4c42887dc438@danielfett.de>  <04440508-a4e7-9cab-288b-2414c72e19ac@danielfett.de>
From: Denis 
Message-ID: 
Date: Tue, 5 May 2020 17:15:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <04440508-a4e7-9cab-288b-2414c72e19ac@danielfett.de>
Content-Type: multipart/alternative; boundary="------------0B71DA77BAE9002A582FD51B"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP: Threat Model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 15:15:16 -0000

This is a multi-part message in MIME format.
--------------0B71DA77BAE9002A582FD51B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Daniel,

Rather than answering between the lines, I place a global answer in 
front of your message.

Depending upon the content of the JWT, two different collaborative 
attacks need to be considered,
one of them being an impersonation attack which can indeed be performed 
using Teamviewer.

The other one, i.e. when the JWT does not contain a set of attributes 
that is sufficient to identify an individual,
is not and cannot be performed using Teamviewer because it does not deal 
with impersonation.

Let us consider a scenario to illustrate this second case.

Alice is Client A while Bob is Client B.

Alice and Bob have both opened an account on a web server allowing to 
make reservations on tennis courts managed by the town of Utopia.

Bob is a resident from Utopia, but Alice is not. Residents from Utopia 
are allowed to perform tennis courts reservations two weeks in advance
while other people can only perform them 48 hours in advance.

An Attribute Server (AS) managed by the town of Utopia is able to 
provide a JWT stating that the holder is indeed a resident of Utopia
(there are about 50.000 residents). The holder can use such a JWT for 
different web sites: library, swimming pool, tennis, ... The web servers
trusting the AS from the town of Utopia ask to present such a JWT once a 
year which may allow to get some advantages during one year.

Bob has already presented such a JWT at the beginning of the year, thus 
he can enjoy making tennis courts reservations two weeks in advance.
Alice is annoyed since most of the time 48 hours ahead, most tennis 
courts are already reserved. So she asks Bob whether he would accept
to request a new JWT token stating that the holder is indeed a resident 
of Utopia. Let us assume that Bob accepts.

When Alice connects to the server, she also ask Bob to connect to the AS 
and to provide her with the JWT and to stay online to perform
all the cryptographic computations she will need to present this JWT to 
the tennis courts web server. For doing this, they both use
a specific piece of software developed for this purpose.

When this is done, during one year, Alice will enjoy to make tennis 
reservations two weeks in advance. At this end of these 12 months,
she will ask Bob to collaborate again.

In this scenario, unless the AS and the RS collaborate, nobody will know 
that Alice and Bob collaborated.

You wrote:

We discussed these kinds of collusion attacks at great length previously 
on this list. My views on them have not changed.

You are not saying in this email what your views are. However, I browsed 
through the last exchanged emails.

On November 8, 2019, under the thread "WGLC for "OAuth 2.0 Security Best 
Current Practice", you wrote:

I have the feeling that this attack aims at breaking a security property 
that OAuth does not claim to fulfill (and that nobody expects OAuth to 
fulfill):

      (...)

      And there are good reasons why this is not captured by the 
security property (Hans' screenshot, for example).

     As far as I know, this property is neither achieved by classical 
first-party session-based authentication/authorization nor by any other 
web-based mechanism, or is it?

I responded to this email:
*
Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
*Denis  Tue, 12 November 2019 09:19 UTC
https://mailarchive.ietf.org/arch/msg/oauth/Gc8T8mRkF5vJT7fV3uSc66B_9Fs/

However, you never responded to it. Up to now, I don't know what "Hans' 
screenshot" was and I don't know the "good reasons
why this is not captured by the security property".

On November 13, I sent an email to the list and to Brian:
*
Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-fett-oauth-dpop-03.txt
*Denis  Wed, 13 November 2019 09:17 UTC
https://mailarchive.ietf.org/arch/msg/oauth/WC8jCC-U3bAhlBHEVRLAdSOuY98/

At the end, I wrote:

     DPoP is not able to counter collusion attacks between clients and 
this should be clearly advertised in the abstract, in the main 
objectives (section 2)
     and in the security considerations (section 9).

You have not participated to this thread. However, DPoP is still silent 
about this kind of attack.

RFC 3552 (Security Considerations Guidelines) states in its Introduction :

     "All RFCs are required by RFC 2223 to contain a Security 
Considerations section.The purpose of this is both
      to encourage document authors to consider security in their 
designs and to _inform the reader of relevant security issues_".

draft-fett-oauth-dpop does not comply with RFC 3552 but it should.

Denis

P.S. It is possible to counter the Alice and Bob collusion attack (ABC 
attack) when specific secure elements are being used.

> Hi Denis,
>
> We discussed these kinds of collusion attacks at great length 
> previously on this list. My views on them have not changed.
>
> Am 04.05.20 um 20:06 schrieb Denis:
>> As soon as a software solution would be available to perform this 
>> collaborative attack, everybody would be able to use it.
>
> Teamviewer is sufficient and widely available.
>
> -Daniel
>
>
>> Denis
>>
>>> Hi all,
>>>
>>> as mentioned in the WG interim meeting, there are several ideas 
>>> floating around of what DPoP actually does.
>>>
>>> In an attempt to clarify this, if have unfolded the use cases that I 
>>> see and written them down in the form of attacks that DPoP defends 
>>> against:
>>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
>>>
>>> Can you come up with other attacks? Are the attacks shown relevant?
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------0B71DA77BAE9002A582FD51B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Daniel,

    


    

    
Rather than answering between the
      lines, I place a global answer in front of your message.

    


        Depending upon the content of the JWT, two different
        collaborative attacks need
        to be considered,

        one of them being an impersonation attack which can indeed be
        performed using Teamviewer.

      
      
The other one, i.e. when the JWT does not
          contain a set of attributes that is
          sufficient to identify an individual, 

          is not and cannot be performed using Teamviewer
          because it does not deal with impersonation.

        

      
Let us consider a scenario to illustrate
          this second case.

      

          Alice is Client A while Bob is Client B.

      

          Alice and Bob have both opened an account on a web server
          allowing to make
          reservations on tennis courts managed by the town of Utopia.

      

          Bob is a resident from Utopia, but Alice is not. Residents
          from Utopia are
          allowed to perform tennis courts reservations two weeks in
          advance 

          while other
          people can only perform them 48 hours in advance.

          

          An Attribute Server (AS) managed by the town of Utopia is able
          to provide a JWT
          stating that the holder is indeed a resident of Utopia 

          (there are about 50.000
          residents). The holder can use such a JWT for different web
          sites: library,
          swimming pool, tennis, ... The web servers 

          trusting the AS from the town of Utopia ask to present such a
          JWT once a
          year which may allow to get some advantages during one year.

          

          Bob has already presented such a JWT at the beginning of the
          year, thus he can
          enjoy making tennis courts reservations two weeks in advance.
          

          Alice is annoyed
          since most of the time 48 hours ahead, most tennis courts are
          already reserved. So she asks Bob whether he would accept 

          to request a new JWT token stating that
          the holder is indeed a resident of Utopia. Let us assume that
          Bob accepts. 

          

          When
          Alice connects to the server, she also ask Bob to connect to
          the AS and to
          provide her with the JWT and to stay online to perform 

          all the cryptographic
          computations she will need to present this JWT to the tennis
          courts web server.
          For doing this, they both use 

          a specific piece of software developed for this
          purpose.

          

          When this is done, during one year, Alice will enjoy to make
          tennis
          reservations two weeks in advance. At this end of these 12
          months, 

          she will ask
          Bob to collaborate again.

      
In this scenario, unless the AS and the RS
          collaborate, nobody will know that Alice and Bob collaborated.

          

          You wrote:

          

           
          We discussed these kinds of collusion attacks at great length
          previously on
          this list. My views on them have not changed.

        
          

          You are not saying in this email what your views are. However,
          I browsed through the last exchanged emails.

          

          On November 8, 2019, under the thread "WGLC for "OAuth 2.0
          Security
          Best Current Practice", you wrote:

          

            
          I have the feeling that this attack aims at breaking a
          security property that
          OAuth does not claim to fulfill (and that nobody expects OAuth
          to fulfill):

         

               (...) 

          

               And there are good reasons why this is not captured by
          the security property (Hans'
            screenshot, for example).

           
          

              As far as I know, this property is neither achieved by
          classical first-party
          session-based authentication/authorization nor by any other
          web-based
          mechanism, or is it?

          

          I responded to this email: 

          

            Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current
            Practice"

          Denis <denis.ietf@free.fr>
          Tue,
            12 November 2019 09:19 UTC

          https://mailarchive.ietf.org/arch/msg/oauth/Gc8T8mRkF5vJT7fV3uSc66B_9Fs/

          

          However, you never responded to it. Up to now, I don't know
          what "Hans'
          screenshot" was and I don't know the "good reasons 

          why this is not
          captured by the security property".

          

          On November 13, I sent an email to the list and to Brian:

          

            Re: [OAUTH-WG] Fwd: New Version Notification for
            draft-fett-oauth-dpop-03.txt

          Denis <denis.ietf@free.fr>
          Wed,
            13 November 2019 09:17 UTC

          https://mailarchive.ietf.org/arch/msg/oauth/WC8jCC-U3bAhlBHEVRLAdSOuY98/

          

          At the end, I wrote:

          

              DPoP is not able to counter collusion attacks between
          clients and this should
          be clearly advertised in the abstract, in the main objectives
          (section 2) 

              and
          in the security considerations (section 9).

          

          You have not participated to this thread. However, DPoP is
          still silent about this kind of attack.

          

          RFC 3552 (Security Considerations Guidelines) states in its
          Introduction :

          

              "All RFCs are required by RFC 2223 to contain a Security
          Considerations
          section.  The purpose
          of this is both 

               to
          encourage document authors to consider security in their
          designs and to inform
            the reader of relevant security issues".

          

            draft-fett-oauth-dpop does not comply with RFC
          3552 but it should.

        

    

    
Denis

    


    

    
P.S. It is possible to counter the
      Alice and Bob collusion attack (ABC attack) when specific secure
      elements are being used.

    


    

    

      
      
Hi Denis,

      


      

      
We discussed these kinds of collusion
        attacks at great length previously on this list. My views on
        them have not changed.

      


      

      
Am 04.05.20 um 20:06 schrieb Denis:

      

      

        
        As soon as a software solution would be available to perform
        this collaborative attack, everybody would be able to use it.

      

      
Teamviewer is sufficient and widely available.

      
-Daniel

      


      

      

        
 

        
Denis

        

          
          
Hi all,

          
as mentioned in the WG interim meeting, there are several
            ideas floating around of what DPoP actually does.

          
In an attempt to clarify this, if have unfolded the use
            cases that I see and written them down in the form of
            attacks that DPoP defends against: 

            https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

          
Can you come up with other attacks? Are the attacks shown
            relevant?

          
Cheers,

            Daniel

          

          

          

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


        

        


        

        

        

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


      

      


      

      

      

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


    

    


    

  


--------------0B71DA77BAE9002A582FD51B--


From nobody Tue May  5 08:18:55 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9613A0810; Tue,  5 May 2020 08:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM1vQOME6dYu; Tue,  5 May 2020 08:18:52 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63443A07A6; Tue,  5 May 2020 08:18:51 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 May 2020 08:18:45 -0700
From: Jim Schaad 
To: 'oauth' 
CC: , 'Benjamin Kaduk' 
Date: Tue, 5 May 2020 08:18:42 -0700
Message-ID: <033601d622f0$7869bfa0$693d3ee0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdYi79fG1jGtBzamQV2voh0MIpYkoA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: 
Subject: [OAUTH-WG] Refreshing tokens on the RS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 15:18:54 -0000

Over in the ACE working group we are currently having a discussion about
refreshing tokens on an RS.  I want to make sure that this is not something
that this working group has already solved.  The basic scenario is:

1.  Client gets token T1 and posts it to the RS
2.  After some time the RS returns and error to the client about an access
issue
3.  Client gets a new token from the AS T2, possibly using a refresh token.
4. Client posts the token T2 to the RS
5.  The RS somehow needs to associate token T1 and T2 for long term security
sessions.

I do not believe that OAuth has this issue because there is not currently
any concept that a token is used for anything other than a single
request/response between the client and the RS.  There is no idea of the RS
storing tokens long term associated with a TLS session that might need to
have the access rights for that TLS session changed.

Please provide any feedback that you might have.

Thanks
Jim



From nobody Tue May  5 08:20:11 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E40D3A087E for ; Tue,  5 May 2020 08:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TubEaLi5drn for ; Tue,  5 May 2020 08:20:00 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8383A0831 for ; Tue,  5 May 2020 08:19:57 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d07 with ME id b3Kv2200J4FMSmm033Kvel; Tue, 05 May 2020 17:19:55 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 05 May 2020 17:19:55 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: <158608868945.18323.557347538112056951@ietfa.amsl.com>
From: Denis 
Message-ID: <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr>
Date: Tue, 5 May 2020 17:19:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <158608868945.18323.557347538112056951@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------EFC32F8748FE63BAF761399D"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 15:20:08 -0000

This is a multi-part message in MIME format.
--------------EFC32F8748FE63BAF761399D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Comments on draft-ietf-oauth-security-topics-15

1) Historically, the acronym RO (Resource Owner) has been used but is 
still used in this document.
     Since a client is not necessarily any more a RO, it would be more 
adequate to use the word "Client"
     instead of "RO"  in this document.

2) The structure of the document is the following:

1.Introduction
2.Recommendations
3.The Updated OAuth 2.0 Attacker Model

It is rather odd to have recommendations placed before the Attacker 
Model. Before providing solutions to some problems,
it is important to understand what the problems are. The Updated OAuth 
2.0 Attacker model should be placed after the introduction.

The "most important recommendations of the OAuth working group for every 
OAuth implementor" should be placed after the "Attacks and Mitigations" 
section.

3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
"updated to account for the potentially _dynamic relationships involving 
multiple parties_".
However, it still misses to address the case of _dynamic relationships 
between clients_, which include scenarios of _collaborative clients_.

Such a collaboration between clients is possible and should be 
considered in the "updated model". Since the Auth 2.0 protocol may be 
used by clients
which are human beings, it cannot be assumed that all the human beings 
in the world will necessary be honest. Whether or not Auth 2.0 is able 
or not
to counter such an attack is another issue.

The collaborative attack should be added to this "updated" model. It was 
missing in the previous model.

In another section, it should be mentioned that OAuth 2.0 is unable to 
counter such an attack.
Stating that such an attack is "out of the scope" of OAuth 2.0 would not 
be an appropriate statement.

It should not be forgotten, that the purpose of this document is to 
inform the reader about _all_ the relevant security issues.

Denis

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>          Title           : OAuth 2.0 Security Best Current Practice
>          Authors         : Torsten Lodderstedt
>                            John Bradley
>                            Andrey Labunets
>                            Daniel Fett
> 	Filename        : draft-ietf-oauth-security-topics-15.txt
> 	Pages           : 46
> 	Date            : 2020-04-05
>
> Abstract:
>     This document describes best current security practice for OAuth 2.0.
>     It updates and extends the OAuth 2.0 Security Threat Model to
>     incorporate practical experiences gathered since OAuth 2.0 was
>     published and covers new threats relevant due to the broader
>     application of OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------EFC32F8748FE63BAF761399D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Comments on
        draft-ietf-oauth-security-topics-15

      
      

          1) Historically, the acronym RO (Resource Owner) has been used
          but is still
          used in this document. 

              Since a client is not necessarily any more a RO, it would
          be more adequate to use the word "Client" 

              instead of "RO"  in this document.

          

          2) The structure of the document is the following:

          

             1. 
          Introduction 

             2. 
          Recommendations 

             3. 
          The Updated OAuth 2.0 Attacker Model

          

          It is rather odd to have recommendations placed before the
          Attacker Model.
          Before providing solutions to some problems, 

          it is important to understand what
          the problems are. The Updated OAuth 2.0 Attacker model should
          be placed after the introduction.
          

          

          The "most important recommendations of the OAuth working group
          for every
          OAuth implementor" should be placed after the "Attacks and
          Mitigations" section.

          

        

      
3) The "Updated OAuth 2.0 Attacker
          Model" is supposed to have been
          "updated to account for the potentially dynamic
            relationships involving
            multiple parties". 

          However, it still misses to address the case of dynamic
            relationships between clients, which include scenarios
          of collaborative
            clients.

          

          Such a collaboration between clients is possible and should be
          considered in
          the "updated model". Since the Auth 2.0 protocol may be used
          by
          clients 

          which are human beings, it cannot be assumed that all the
          human beings
          in the world will necessary be honest. Whether or not Auth 2.0
          is able or not
          

          to counter such an attack is another issue.

          

          The collaborative attack should be added to this "updated"
          model. It
          was missing in the previous model.

        

      
In
          another section, it should be mentioned that OAuth 2.0 is
          unable to counter such an attack.

          Stating that such an attack is "out of the scope" of OAuth 2.0 would not be an
          appropriate statement.

        

      
It should not be forgotten, that the
          purpose of this document is to inform the
          reader about all the relevant security issues.

          

          Denis

    

    

      
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-15.txt
	Pages           : 46
	Date            : 2020-04-05

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


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


    

    


    

  


--------------EFC32F8748FE63BAF761399D--


From nobody Tue May  5 11:20:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006E3A0BA5 for ; Tue,  5 May 2020 11:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll0-a0XZD2p3 for ; Tue,  5 May 2020 11:18:39 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABFC3A0C08 for ; Tue,  5 May 2020 11:18:36 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id t12so2643320ile.9 for ; Tue, 05 May 2020 11:18:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=Fyo1Bcpbdc0UIHJTV/rjzfwtN3xZfE92eoU/W6NK3p4=; b=mZinp2G+6Y7fJRuC2CjkbRrgAWZzrjgfWvif+nMOMGQtQjgqCf+R0bf2o+sP8bzzjz mtyotlVeVHnoJTXE00u2rt9gRvtksTRWp5mTLrQo+68WxsZWUYjCNaZzYQO1KGpbHiKS 8f5cz+iXRHqTQYlUDsSoRPYwi41T0w8vHE1TRcwyTOCVE11tkUBonfNdG02TYYWbsAir 9Zkj9qKjH8qbh4/+M7D6QqO+V9a96gJH4TpkSkjGAEX6IQ61vWAEj3epT4T+iDk5IZT0 hZJOlMJA84Xsb8yRF0n8u5RnL475gV5VwvTtqCvsjKnKphA1RjEv+ED+fAXi07hIHs03 JxMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Fyo1Bcpbdc0UIHJTV/rjzfwtN3xZfE92eoU/W6NK3p4=; b=FSDznZViPJfRshmzTQCPLNRVncqyhUzddDQpawB8F89iBbId6QP9Np3W9loce2hxmC BBhDc4REDK4Rb4+gTwrQnjbyo1NRQ4v6ALgqCeSDJ5u30pB/xw5U+FT88ZY9dmziXDoO 8YG5fruj7S6OG/1OEfhKXhP9IKMXBf8fE0Es9JFRZIFXDS3ZuRJxYmejATuj89QNXYhY X418DjsnBfIm3pyfMa0gFKW6adIxFfDC3JcoeHz5idHdtetDR+nyOzK2StgBagtq1QuO q0VU6VKqxDjH+g6mHpdGgbf4vS76GuQ7E6pQyLDPjYLB6cfTPA8t018sVzzl3/1x2Np2 ey1Q==
X-Gm-Message-State: AGi0PuYI2bm24yt2DS+uj5PlD/zEdLCl8gcHimbQrTAjD0UDenrCONNg wL/9kc3xiw7PY7r2XS1l/+Bqou5MagyXma5E10sZXLA0IzMkLQ==
X-Google-Smtp-Source: APiQypKEnFW/V5uxC5Per+ZyIaB7eqG81dGru583wLJT5uiCviZPxVAwuMmh/C8r6jPeL9S0TT4VgCR4bvb7NBAytbg=
X-Received: by 2002:a92:d3c5:: with SMTP id c5mr5070741ilh.73.1588702715738; Tue, 05 May 2020 11:18:35 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Tue, 5 May 2020 14:18:24 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000006827905a4eaad43"
Archived-At: 
Subject: [OAUTH-WG] A *Short* 3rd WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 18:18:53 -0000

--00000000000006827905a4eaad43
Content-Type: text/plain; charset="UTF-8"

Hi all,



This is a 3rd working group last call for "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens".



Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07



Please send your comments to the OAuth mailing list by May 12, 2020.



Regards,

 Rifaat & Hannes

--00000000000006827905a4eaad43
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,<=
/p>
=C2=A0
This is a 3rd working group last call=
 for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens".<=
/p>
=C2=A0
Here is the document:
https://tools.ietf.org/html/draft-i=
etf-oauth-access-token-jwt-07=C2=A0=C2=A0
=C2=A0
Please send your comments to the OAuth mailing list by May 12,=
 2020.
=C2=A0
Regards,
=C2=A0Rifaat & Hannes


--00000000000006827905a4eaad43--


From nobody Tue May  5 12:15:43 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FB53A07BB for ; Tue,  5 May 2020 12:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aueb.gr
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egsegh7JSnw5 for ; Tue,  5 May 2020 12:15:38 -0700 (PDT)
Received: from blade-b3-vm-relay.servers.aueb.gr (blade-b3-vm-relay.servers.aueb.gr [195.251.255.106]) by ietfa.amsl.com (Postfix) with ESMTP id ED3783A07BA for ; Tue,  5 May 2020 12:15:37 -0700 (PDT)
Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [195.251.255.217]) by blade-b3-vm-relay.servers.aueb.gr (Postfix) with ESMTP id A1E1B7EA for ; Tue,  5 May 2020 22:15:35 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aueb.gr; s=201901; t=1588706135; bh=VpU76MSjxME6f/GnpEMj0B01Uu0CQo1H+Hki9SGSuQY=; h=From:To:References:In-Reply-To:Subject:Date:From; b=dIN1UecpbcB3lKhi2gMKVJjquyd+e5U+IusZwr1x8jTvUZjbMC8QxSdCE1oege2OH kizX2ddoY+K9snW+orLBJ++PqkBZ8OtjohOtKqalY82hsWrIEjdHXdeA9kpHkrm3xI WkpCh+6cIohTLLApcZhULlezqjyU/3AiL+DXygvDUIJ4fV7hS7mvRSwVRdzgPw2VWU dDVqlSi/j1HTVhXWSzczWN73+GfUl9CfanvFyM4Eq/AKHdCOHJwdpv8HD6vIBHDXjK Nkv0CD0W2nlE6NcyFGWKv/u9vKkXMJRaPga/UdsNmsYKLX0lP+CcZTXgbvg6SFj7ss +SHeQJOeiuf4w==
Received: from DESKTOP7VDSLBL (athedsl-238563.home.otenet.gr [85.74.251.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fotiou) by blade-a1-vm-smtp.servers.aueb.gr (Postfix) with ESMTPSA id 81BADB5B for ; Tue,  5 May 2020 22:15:35 +0300 (EEST)
From: "Nikos Fotiou" 
To: "'oauth'" 
References: <158835743733.12112.7484502726888997082@ietfa.amsl.com> 
In-Reply-To: 
Date: Tue, 5 May 2020 22:15:33 +0300
Message-ID: <02cb01d62311$8ce1e900$a6a5bb00$@aueb.gr>
X-Mailer: Microsoft Outlook 16.0
Content-Language: el
MIME-Version: 1.0
Thread-Index: AQJoP+p0lhF/AEoO/uEYyKFfTlmrcwIAWYuCp2WfHjA=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_02C4_01D6232A.B1BF9650"; micalg=2.16.840.1.101.3.4.2.1
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 19:15:41 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02C4_01D6232A.B1BF9650
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_02C5_01D6232A.B1BF9650"


------=_NextPart_001_02C5_01D6232A.B1BF9650
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

There was some discussion about adding =E2=80=9Cserver =
contribution=E2=80=9D in the DPoP proof. I was wondering if the =
=E2=80=9Cchallenge=E2=80=9D server response described in section 6 can =
include such a contribution (e.g., a server generated nonce).

=20

Best,

Nikos

=20

From: OAuth  On Behalf Of Brian Campbell
Sent: Friday, May 1, 2020 10:03 PM
To: oauth 
Subject: [OAUTH-WG] Fwd: New Version Notification for =
draft-ietf-oauth-dpop-01.txt

=20

I've pushed out a -01 revision of DPoP hopefully allowing folks enough =
time to read it before the interim meeting on Monday (apologies that it =
wasn't sooner but the edits took longer than expected or hoped). For =
ease of reference the changes in this revision are summarized below. =
There are, of course, still outstanding issues and discussion points =
that I hope to make some progress on during the interim meeting on =
Monday.

=20

   -01


   *  Editorial updates
   *  Attempt to more formally define the DPoP Authorization header
      scheme
   *  Define the 401/WWW-Authenticate challenge
   *  Added "invalid_dpop_proof" error code for DPoP errors in token
      request
   *  Fixed up and added to the IANA section
   *  Added "dpop_signing_alg_values_supported" authorization server
      metadata
   *  Moved the Acknowledgements into an Appendix and added a bunch of
      names (best effort)

=20

---------- Forwarded message ---------
From:  >
Date: Fri, May 1, 2020 at 12:24 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
To: Torsten Lodderstedt  >, David Waite =
 >, =
John Bradley  >, Brian =
Campbell  =
>, Daniel Fett  >, =
Michael Jones  >




A new version of I-D, draft-ietf-oauth-dpop-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-ietf-oauth-dpop
Revision:       01
Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the =
Application Layer (DPoP)
Document date:  2020-05-01
Group:          oauth
Pages:          22
URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




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




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


------=_NextPart_001_02C5_01D6232A.B1BF9650
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi =
all,
There was some discussion about =
adding =E2=80=9Cserver contribution=E2=80=9D in the DPoP proof. I was =
wondering if the =E2=80=9Cchallenge=E2=80=9D server response described =
in section 6 can include such a contribution (e.g., a server generated =
nonce).
 
Best,
Nikos
 
From: OAuth =
<oauth-bounces@ietf.org> On Behalf Of Brian =
Campbell
Sent: Friday, May 1, 2020 10:03 PM
To: =
oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Fwd: New =
Version Notification for =
draft-ietf-oauth-dpop-01.txt
 
I've pushed out a -01 revision of DPoP hopefully =
allowing folks enough time to read it before the interim meeting on =
Monday (apologies that it wasn't sooner but the edits took longer than =
expected or hoped). For ease of reference the changes in this revision =
are summarized below. There are, of course, still outstanding issues and =
discussion points that I hope to make some progress on during the =
interim meeting on Monday.
 
   -01

   *  Editorial updates
  =
 *  Attempt to more formally define the DPoP Authorization =
header
      scheme
   *  Define the =
401/WWW-Authenticate challenge
   *  Added =
"invalid_dpop_proof" error code for DPoP errors in =
token
      request
   *  Fixed up =
and added to the IANA section
   *  Added =
"dpop_signing_alg_values_supported" authorization =
server
      metadata
   *  Moved =
the Acknowledgements into an Appendix and added a bunch of
  =
    names (best effort)
 
---------- Forwarded message ---------
From: <internet-drafts@ietf..org>
Date: Fri, May 1, =
2020 at 12:24 PM
Subject: New Version Notification for =
draft-ietf-oauth-dpop-01.txt
To: Torsten Lodderstedt <torsten@lodderstedt.net>, David Waite <david@alkaline-solutions.com>, John Bradley =
<ve7jtb@ve7jtb.com>, Brian Campbell <bcampbell@pingidentity.com>, Daniel Fett <mail@danielfett.de>, Michael Jones <mbj@microsoft.com>



A new =
version of I-D, draft-ietf-oauth-dpop-01.txt
has been successfully =
submitted by Brian Campbell and posted to the
IETF =
repository.

Name:          =
 draft-ietf-oauth-dpop
Revision:      =
 01
Title:          OAuth 2.0 =
Demonstration of Proof-of-Possession at the Application Layer =
(DPoP)
Document date:  2020-05-01
Group:      =
    oauth
Pages:          =
22
URL:            https://www.ietf.org/internet-drafts/draft-ietf-oauth-d=
pop-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/=

Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-oauth-=
dpop
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dp=
op-01

Abstract:
   This document describes a =
mechanism for sender-constraining OAuth 2.0
   tokens via a =
proof-of-possession mechanism on the application level.
  =
 This mechanism allows for the detection of replay attacks with =
access
   and refresh tokens.




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


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

------=_NextPart_001_02C5_01D6232A.B1BF9650--

------=_NextPart_000_02C4_01D6232A.B1BF9650
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEj4w
ggQxMIIDGaADAgECAgEAMA0GCSqGSIb3DQEBBQUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7
SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3Jp
dHkxQDA+BgNVBAMTN0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg
Um9vdENBIDIwMTEwHhcNMTExMjA2MTM0OTUyWhcNMzExMjAxMTM0OTUyWjCBlTELMAkGA1UEBhMC
R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg
Q2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2gg
SW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
qVMA4y6m9o76YNgtlT74LCpUTs25hGGUWE+PPYvkQ/N1iY1R5MM30oqITXketxLdQ3hKipLm10jV
D6Q6KUQ1uAf2aB1VzThR8IwkMYWvg8l96Xev7Rp7nRf5s504UA+mWnmRgK83rqbTMfu1JgmdPFrv
UcUr35Zd6zIeAtpwSexuDMiaN4338TZgSyYsgp7QePMND2OkUTDh+SsnEgfY6r0YYpiwWTd9vu7z
IFFCWoPvk7ppFfFinZ+ZOYKht3Qui9TFC3sv8MgK2j15CpqTHKUocnORQ5qn0U2FhLmpdI8UQMfc
3qxBZGy0GZsCY20kZI9EsiXqzl10DGMyXI2H5QIDAQABo4GJMIGGMA8GA1UdEwEB/wQFMAMBAf8w
CwYDVR0PBAQDAgEGMB0GA1UdDgQWBBSmkUL9E2FKI54IpCnl2BMEI+5BJTBHBgNVHR4EQDA+oDww
BYIDLmdyMAWCAy5ldTAGggQuZWR1MAaCBC5vcmcwBYEDLmdyMAWBAy5ldTAGgQQuZWR1MAaBBC5v
cmcwDQYJKoZIhvcNAQEFBQADggEBAB/veUHhe24/soyGN0JKThw3Ho1muiSByU8SDyHAA5eGJW1d
0yIpqGyiDanrPQZbmTrHzMOaNH+rDshOHOH65NzNDb6/JP5s52vCDcgGnk6NYSimav3l9mLqGDxO
oFOdsjqc66WckRa2TYLgDAVIqWz1zPjLnUm08AKl/XAD7Yohpa4ThknDM3O+hzt0ixdFJkwWkYP+
Z33NTWNn+vMDEpZ4Bo2xZ+2OP76fTwL1swkv80yH3yrLlXwBzKw2er+ic3r3j8G1mqEUso8znw3v
Itxme4S9RRcGPTzKuXc0j8rqzz8xPuOI44BJJciXtZ2amU2wPPhKAJtk3Z85S9En17gwggbQMIIE
uKADAgECAhBAB3aGT+I5a2zJV9kPcbUZMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQGEwJHUjFE
MEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0
LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQg
QnVzaW5lc3MgQ0EgUjIwHhcNMTkxMjEyMTQxNzU4WhcNMjExMjExMTQxNzU4WjCCAQkxCzAJBgNV
BAYTAkdSMQ8wDQYDVQQHDAZBdGhlbnMxNDAyBgNVBAoMK0F0aGVucyBVbml2ZXJzaXR5IG9mIEVj
b25vbWljcyBhbmQgQnVzaW5lc3MxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtleSBjcmVh
dGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMQ8wDQYDVQQEDAZGT1RJT1kxETAPBgNVBCoM
CE5JS09MQU9TMRMwEQYDVQQFEwozODY2OTQxMjIxMRgwFgYDVQQDDA9OSUtPTEFPUyBGT1RJT1kx
HTAbBgkqhkiG9w0BCQEWDmZvdGlvdUBhdWViLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAgLLzGBqZBB4A0EYdBSjLSUYjNMZYSS14Z4+Esf6iK7wrSw8pOfjLBMqtJOywazPxWgmm
vhk6PaCLhZYgwPqdGQk3z+m3Hm2ao9fnFghTIBhXyypOJVCEVNblcY1r6+HZZLZZ/Z5NnMLuNKK+
uWQ7dRR/GZDOFGcnOtcmMx9GKrgSrawVOsghzBRg5wLbvCaCNJsJ90mRYsyUjkg9OglG2dzZ7Bi0
2BzozUwP69dFaKG7ml12C9FwQiaBURg3dDbgl7AuGY1AZcqBAPwKNni0Jkpl5XL2JzjbzQj73EbT
FMrsgG1PbGw/uZgQyCqAVHS1HiIJhyMTn7cttd5CobkMMwIDAQABo4IBqTCCAaUwHwYDVR0jBBgw
FoAUd2BZxxknkkBQvIKZbY8+SdAQ9CowbQYIKwYBBQUHAQEEYTBfMDoGCCsGAQUFBzAChi5odHRw
Oi8vcmVwby5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhQXVlYkNBUjIuY3J0MCEGCCsGAQUFBzABhhVo
dHRwOi8vb2NzcC5oYXJpY2EuZ3IwGQYDVR0RBBIwEIEOZm90aW91QGF1ZWIuZ3IwWAYDVR0gBFEw
TzAIBgYEAI96AQEwQwYNKwYBBAGBzxEBAQICATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3JlcG8u
aGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgor
BgEEAYI3CgMMMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmx2MS5oYXJpY2EuZ3IvSGFyaWNh
QXVlYkNBUjIvY3JsdjEuZGVyLmNybDAdBgNVHQ4EFgQUcMJMYLF3+xjl9x4Fc4V2qRdAoVIwDgYD
VR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAo/QEb7ED5Z7e3qdVPfIdKRpnLQ+JH3V7w
4CKouEZkSjH2m+y0WOtMoF4cPCNrMH90n/IH9QuGcyYALRQTXAKsgF5s5TIeHc8fpFAesjoVjTHT
ijK94b4ekh81jU/o8sRhsfWjPzAjzhSogWuh9yYox7fx0pvnux9lGE2+mVhE0xJqzP4N6zGmVsYY
Og6YfOtjYK46lvT5WOKkdK9lD9S3vmws0BPOCirvIqc9/fzKngZMTcsXMEZp91z40SuUxn48P370
TKgvzIkmnDVB/iOobkdErAgp5j2o6s/Bt2m91VwLW3xOIV4F9y8BGOxsRqvRkv7wMKmhTjkAT+MV
F7uw1S+vmeTeL+pdFUBAKJRizEqjCL6D7ZwpKszeMhi6Sx31ooOPpTOWtPh/fLfRRJBYNFcrYgMl
Br0WWe1nIYajWskliR+5HNyNY8/zQApm9SGqr4VjaYdEwnU+NVLiZ2pikWyrg5B8QyqcJCNdZRez
jOPqM6DN+t52HMSnqHFxsy6cqOfqOSAsitZT2LkBWVDj3TxkENnw04hPUS4ip48jMB0szuajEMmK
qs5/uGY9EyQ3bHlDDWQxu/DULZJOcsZPX67mcOTLfXOXFnyW/gOGbvCgitlimm7xrDHmVWvB4AE7
XPK7ogjGmG1qEq7vnYOcgj93DGizi+QkmVMCJwpGYjCCBzEwggYZoAMCAQICCBjdh64fS7Z7MA0G
CSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMg
YW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMTN0hlbGxl
bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEwHhcNMTUw
NzI4MDcxMDQ4WhcNMjMwNzI2MDcxMDQ4WjCBjzELMAkGA1UEBhMCR1IxRDBCBgNVBAoTO0hlbGxl
bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9yaXR5MTow
OAYDVQQDEzFBdGhlbnMgVW5pdmVyc2l0eSBvZiBFY29ub21pY3MgYW5kIEJ1c2luZXNzIENBIFIy
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjTO6hsbRRbmkpEjRUM1K7/Mn2XgBgh/T
p6AbDXt5rS/oFBc/GJ5bCJFc7P1d1LHMSM1VT0advzlwE2xdnR0X9ThYKIm67gOAs1RUHxLqSYcr
g2qkGdm1LadSwfn8KTDAxXynmVHhduU5jOTWS/LbX18EkZQ0tWiTEHxN+Uj7RFGzPrrEC6C3x+W/
jZ9uZEfjLOxC0FHkYGndlHWh2SnoJyKvcWXE1F3DEdsGhm7gK/wxRG70U1ryihV3upd43YNdxEzB
BEP2RIR8UDPLt4UpdfmmTk9uVJR6waYYtpnF10PSpuMRXNqV2dtlXCz8OEuoWFSlJbUF7VmwiZID
g5P7INZ9bRWercaBquvOdDk0hBcuUfadx7TfPQHRhhUAP9UGvGcJsX7gP/3R0eUMGC6QH+Ly5LKd
fHpubVABNQnXcKXgVQtjJWGObSGsnz/X3PmhF+MYlQRtrT7852Paf0xnQ1klXaLpd04jRK/EoVrJ
s9jZWggPatQsX9aWuXR7xWGqOR3kT7aetAwk3FgT896eUj5V1C5eJZy9b21SJm5ux2WtmrcpCtDc
YSafDaJ/0toGUPnZZnDMyyKYbuQvNu7AVYcT5uFTu84JKTqjl8jrXb4PITFN7rjKPOb0geJm+RtT
De9Shan4d0vty9xWUDvMV5utJPIkreaRdGDbbNJQkP0CAwEAAaOCAocwggKDMA8GA1UdEwEB/wQF
MAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR3YFnHGSeSQFC8gpltjz5J0BD0KjBGBgNV
HR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEuaGFyaWNhLmdyL0hhcmljYVJvb3RDQTIwMTEvY3Js
djEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9E2FKI54IpCnl2BMEI+5BJTBuBggrBgEFBQcBAQRi
MGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLmhhcmljYS5ncjA7BggrBgEFBQcwAoYvaHR0cDov
L3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhUm9vdENBMjAxMS5jcnQwggE3BgNVHSAEggEuMIIB
KjCCASYGBFUdIAAwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5nci9kb2N1bWVu
dHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2Vh
cmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoGJVGhpcyBjZXJ0
aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91ciBDUFMuIFRoaXMgQ2VydGlm
aWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBlZHVjYXRp
b25hbCBwdXJwb3Nlcy4wLQYDVR0eBCYwJKAiMAmCB2F1ZWIuZ3IwCYEHYXVlYi5ncjAKgQguYXVl
Yi5ncjANBgkqhkiG9w0BAQsFAAOCAQEAhSXJoQDbTRBYH549pfk9+3CjT+HnAcFajp60aV8UYR63
DZflolPCDagaRxADLd3SpbOuGlRGNw+MgYpAp/d6i5BfVpjMVIhp5E7zr6TDJgVIwt2UxuLejfow
umCNkRJD+RrdUcLKHzcPOfSD40MRHprehXT1bvyuka26ogF6U0T2uEDoOIaObV/RS9wgGx9y63/Q
Ic/tsZNQ3pzcAbTecnax6ITfSvnnfeMol6IcS+rKxPwKjPPFQq93qT8w61qe+zEx54vRwJXi241e
dkTmBTJddM5Cdhxxy98xYX+eYNnf5x96vVDQ1qc2wcecMHADZBrfVV/tx0Ev6hTlYBhOmzGCBEUw
ggRBAgEBMIGkMIGPMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5k
IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBV
bml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MgQ0EgUjICEEAHdoZP4jlrbMlX2Q9x
tRkwDQYJYIZIAWUDBAIBBQCgggJxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTIwMDUwNTE5MTUzM1owLwYJKoZIhvcNAQkEMSIEIPGH0pG8WCYP7c826oyEeXNfuPr/
DHViCTqTx5w5TFSqMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMIG1BgkrBgEE
AYI3EAQxgacwgaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBh
bmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5z
IFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZ
D3G1GTCBtwYLKoZIhvcNAQkQAgsxgaeggaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxs
ZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6
MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBS
MgIQQAd2hk/iOWtsyVfZD3G1GTANBgkqhkiG9w0BAQEFAASCAQBuIA8C3L4BE3pgww4dJe3z0Ael
Kmvtlvu94LQdRnfkovtd6OhkuQPm2IM2HPeFA4zRx+0nY+VSUKrzdBz1MdNJ1jGCf3BGpcV8EIjk
XiJHtvKUh6f3Dmciv/Fki0QwuzrQ8+Fap+wSGoZWl7H5wQqQ1XhpYXb9DzOR4bbISbum6z0n/Q54
uHAy785PeCM3UqB340ghOTJ1QT/PaMoxCIRQTHPV4NQbcI2IhIREtYC+uQZO7yLUMTuwhACLSMV3
6srP+o2KtqVJ6Kv4Fc240pcBeShhJmBriObRuO98qaLsPrO/3dBJQBMbSl8CTf23Mf7acgZVUZko
vQvfDSQ6TWL0AAAAAAAA

------=_NextPart_000_02C4_01D6232A.B1BF9650--


From nobody Tue May  5 13:53:17 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872B13A0AD0 for ; Tue,  5 May 2020 13:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoWDUVkANRwZ for ; Tue,  5 May 2020 13:53:10 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79E93A0ABE for ; Tue,  5 May 2020 13:53:09 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id s9so159858lfp.1 for ; Tue, 05 May 2020 13:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VxRb8sfwEIXCPje4IJST2Axz9fuNbj97RUBQ5e1o+5M=; b=Cg1B1OlzJO7KSy7Ekn2cSd1pWAUalyc45hFLYUVPug7b1kb4cwLhDoohhQQ4lvsjpc 6wtazLrNysZCkL2hKWfxCjx9FEw/yArCaQ5tQowe0L0VLXqyFv/s++kRrZjI6mxInyo+ bKs9ZC3z/Ylt9j1aPS8U/578ccZDpbqp0HTSUVdEUu8lg1yODD3C2KDFJM/4o1dJtEbj buf7xkyDhL4tZ96TgF9jNTlWWF3UZKbXTLdlYzLvi6wY9l0WJgcpznRrd27Y7ntNUpkQ BIV568JTPxyq0urOHaI3J9tw1ftQhZVQtvraiPlNJN9062NQT7EKKJ9dIbncRx7A8KCw tVfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VxRb8sfwEIXCPje4IJST2Axz9fuNbj97RUBQ5e1o+5M=; b=DBhXl3vltveUhAQipHITD7/m3137Tz4DAnXnnqt7gHoU2+iBzbsRRK5/tFqejAzjFO c+uBqZGziSZbNFxoMmNqSgNhNQhDCDdeFAvQi4SUfyzXxNzcIZxfcnhrYkkCc0RhbE4Y ADYMDmiwzoPBf4/zlbW83tPAShKLZI73tRNsaOivmgN8E72F0ZX9epedN5+Lr0vVrjRD Ll+dyPxDMzIZuHpLaHOEc7wE1UOtN4R2zUqS0uQrsZDsE7zgjzLoGkokk2AqF4Sc6K4+ eVclwxLPlPaz6POqudEPmJwg99lA8MvB6Kxr9ajSCGeVFiWw2AwlpYDtNjoWr62yCGG+ Kv0Q==
X-Gm-Message-State: AGi0PubhXroKY3vo9bOnzS5XdKA4G9Kq43uC9AYmJZdx4NrghTl8TMAO P2lYXHC1vDvpEPLx59q9XXwQk9wFd0MeHBEaDofg7ScupZ7SUc0f9Fe2JL9Qf68xzpRE1vZtzas 51NveqSRg6Uqk/w==
X-Google-Smtp-Source: APiQypJhOGKILX1pFdkHbxQgs5umKtdDAed5mlsbQziPPi3JwH7mFHg/YBQF2S1TSG4+rU5bpGHKADYwtT28ODWlYnY=
X-Received: by 2002:ac2:57cd:: with SMTP id k13mr2127786lfo.104.1588711987769;  Tue, 05 May 2020 13:53:07 -0700 (PDT)
MIME-Version: 1.0
References: <158835743733.12112.7484502726888997082@ietfa.amsl.com>  <55D70F29-CF65-405B-AAE0-4978C25C8FCF@forgerock.com>
In-Reply-To: <55D70F29-CF65-405B-AAE0-4978C25C8FCF@forgerock.com>
From: Brian Campbell 
Date: Tue, 5 May 2020 14:52:41 -0600
Message-ID: 
To: Neil Madden 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000ae935c05a4ecd5dc"
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 20:53:15 -0000

--000000000000ae935c05a4ecd5dc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Neil.  I do appreciate your review and feedback (even if it takes me
a nontrivial amount of time to reply). I've attempted to respond to things
inline below.

On Mon, May 4, 2020 at 5:51 AM Neil Madden 
wrote:

> Some review comments:
>
> Section 1:
> I think terms like =E2=80=9Crelatively simple=E2=80=9D are subjective and=
 should be left
> out. I don=E2=80=99t think the machinery of JWS signature verification (a=
nd
> associated security issues) is necessarily simple at all.
>

That's fair. It was subjectively true to me as I wrote it but I take your
point.


>
> =E2=80=9Cstronger methods =E2=80=A6 such as [RFC8705] or [token binding]=
=E2=80=9D
> I would dispute that these are actually stronger methods in the context o=
f
> an SPA, putting aside the usability issues. As has been discussed before,
> TLS is a shared context in a web browser - the same TLS connection will b=
e
> reused for all requests, regardless of the origin they come from. The
> situation is better for cert-bound ATs because you need the CORS
> Access-Control-Allow-Credentials to be set to make a cross-origin request
> with a client certificate, but as I describe below there are also other
> attacks against TLS that don=E2=80=99t apply to DPoP (and would be a good=
 reason to
> adopt DPoP).
>

The =E2=80=9Cstronger methods" was preceded with "potentially" in hopes of =
toning
down the strength of the statement about strength somewhat. But yes it
could be reworded to take away any comparative language.



>
> I think this section should also mention mobile use-cases, as IMO the cas=
e
> for DPoP is much stronger in those environments. Many of our customers ar=
e
> looking for a PoP solution for mobile and have rejected mTLS for various
> reasons (which have previously been discussed on this list, e.g.
> incompatible middleboxes). DPoP is potentially really nice for these
> environments as they often have a nice secure element available to store
> the private key and are much less susceptible to XSS and so on, but may
> still worry about a malicious RS.
>

Agree that mobile/native use-cases deserve a mention.


> IoT applications may also be a use-case as requests are often relayed ove=
r
> multiple hops and different transport protocols, so TLS cannot be used fo=
r
> end-to-end security (although in that case you probably want a full reque=
st
> signing approach).
>
> Section 2:
> I think the =E2=80=9CMain Objective=E2=80=9D in section 2 could be improv=
ed. The vast
> majority of the mechanisms described in the draft do nothing to address
> this main objective, and are in fact intended to prevent DPoP proof repla=
y
> which is relegated to a =E2=80=9Csecondary objective=E2=80=9D in section =
9. Only the =E2=80=9Chtu=E2=80=9D
> claim really has anything at all to do with the main objective. I think
> some of these secondary objectives, especially the anti-replay one, shoul=
d
> be brought forward to section 2 to better justify what follows.
>
> It has been mentioned several times on this list that an audience
> restriction in the AT would also solve this main objective, and the
> response has generally been that adding audience restrictions is hard in
> practice - e.g. due to the AS not knowing where the AT is intended to be
> used. I think it would be useful to explicitly add some discussion of thi=
s,
> and perhaps a comparison with things like resource indicators that
> presumably could solve at least some of the issues with audience
> restrictions.
>
> I think there *are* significant advantages of DPoP that address real-worl=
d
> attacks that cannot be solved in any other way currently. For example, I
> was reading [1] recently about CRIME/BREACH attacks against CSRF tokens a=
nd
> it occurred to me that exactly the same kind of attack is a real threat t=
o
> access tokens in a browser and that DPoP is an effective mitigation again=
st
> it. To summarise, these attacks exploit vulnerabilities in TLS when
> combined with compression (either in TLS itself or HTTP compression) and
> can allow an attacker to steal bearer tokens or cookies after observing
> enough requests with the same token (and being able to influence some oth=
er
> content in the same request/response). One recommended mitigation is to
> randomize tokens so that they are different on every request, which thwar=
ts
> the attack. Although DPoP doesn=E2=80=99t directly randomize the AT the A=
T is
> useless without a DPoP proof and a unique =E2=80=9Cjti=E2=80=9D claim ens=
ures that the DPoP
> proof is randomized and so not recoverable through this attack. Given tha=
t
> BREACH is largely unmitigated in practice, due to the usefulness of
> compression, adding a description of this attack to the justification wou=
ld
> IMO significantly improve the rationale for DPoP.
>

Daniel is way way way more adept than I when it comes to threat and
attacker modeling. He also penned the original text of the draft, much of
which is still present. In trying not to step on his toes and also be
mindful of the disparity in our competency, I'm really hoping that he can
do an overhaul of the threat model, objectives, security considerations,
etc. to address this and similar commentary in a more meaningful way. The
inclusion of BREACH seems worthwhile, thanks for the pointer/suggestion. I
think I'd also like to see some discussion of mitigations for unforeseen
"stuff happens" kinds of threats. Like the cloudflare parser bug of a few
years ago that leaked data including tokens and cookies. The specifics of
that sort of thing probably don't belong in a document like this. But bound
tokens would be protected against reuse when leaked like that or via other
many unforeseen ways.



>
> Section 3:
> The second bullet point of step (B) isn=E2=80=99t clear - is it implying =
that
> refresh tokens for confidential clients shouldn=E2=80=99t be DPoP-bound? =
Must not?
>

The intended intent of the document is that refresh tokens be DPoP bound
only when issued to public clients. RFC6749 already requires that an AS
bind refresh tokens to the client to which they were issued and that
confidential clients (those having established authentication credentials
with the AS) authenticate to the AS when presenting a refresh token. Thus,
refresh tokens issued to confidential clients are already
sender-constrained to the client and its credentials.


Step (C) implies that only JWT-structured ATs or token introspection are
> supported for communicating the public key. Presumably deployers are free
> to use another secure mechanism if they wish?
>

Yes. That wasn't meant to imply that other mechanisms weren't possible.
Rather just to highlight the cases where defined interop between AS and RS
is in scope of this doc. We'll look at rewording this so as not to imply
exclusivity.


>
> The last bullet point about requiring a DPoP proof for refresh tokens is
> ambiguous about what happens in the case of confidential clients if the
> refresh token is not DPoP-bound. Do they not supply a DPoP proof at all
> (and it reuses the original one), or must they supply a new one? Can they
> supply a *different* DPoP proof to e.g. rotate their key pair?
>

I'm thinking that that bullet point should be removed from this
introductory part and hopefully those questions are or will be addressed
elsewhere in the document. But the idea is that a client will always supply
a DPoP proof in the token request and issued access tokens are bound to the
proof's public key. For a public client, it has to be a proof for the same
key for the duration of the refresh token (b/c the RT is bound). A
confidential client can send a DPoP proof for a different key to
effectively rotate the key pair.


>
> Section 4:
> Maybe a forward reference to section 6 when mentioning the DPoP header
> field, as that=E2=80=99s where it is defined.
>

Hrm. Section 4 here is trying to define the DPoP header field. I guess that
needs some work/improvement in the document. Section 6 defines the DPoP
Authorization Scheme, which is related to but different from the header
field.


>
> 4.1:
> I=E2=80=99m not keen about including the full =E2=80=9Cjwk=E2=80=9D in ev=
ery DPoP proof. It never
> changes for the life of the AT and adds considerable overhead to the size
> of the proof. If the RS is using token introspection (with opaque ATs) th=
en
> it would be much more efficient to return the JWK in the token
> introspection response and let the RS cache that. Alternatively the AS
> could publish the JWK under a URL on behalf of the client and include a
> =E2=80=9Cjku=E2=80=9D header instead.
>

There are a number of different ways the various bits of information could
flow. And there can be advantages/disadvantages depending on other things
like opaque v.s. structured ATs and caching and more.

As such, I don't believe there's necessarily a right way to do things. But
the model we've tended towards here and are pretty happy with is that the
proof is sent the same way to both the AS and RS. And that proof contains
the key to which tokens can be bound or such a binding can be checked.



> In the last paragraph, is it worth explicitly calling out things like
> GraphQL as not suitable for DPoP due to the fact that they reuse the same
> URI and HTTP method for all requests?
>

Maybe worth mentioning but seems more like a security consideration thing.



>
> 4.2:
> I feel like this section should contain a forward reference to section 6,
> otherwise it appears to suggest that verifying the signature and claims i=
s
> sufficient - without the crucial step of ensuring that the JWK matches th=
e
> actual access token.
>

I'll look to add such a reference and better explain here that verifying
the signature and claims of the DPoP proof JWT is what provides (some
reasonable level) of assurance that the caller holds the private key
corresponding to the public key in the proof. But not more than that on
it's own.


> The potential for implementers to get this wrong is another reason to
> prefer not including the JWK directly in the DPoP proof but instead have =
it
> retrieved from the access token (either as a cnf or from token
> introspection). That makes it much harder to validate a proof that is
> unrelated to the AT.
>

There are a variety of different ways this particular cat could have been
skinned. As I mentioned previously this model where the proof is the same
regardless of where it's used is the method of skinning that's kind of
emerged as the preferred. Of course there are some trade offs and
implications with whatever approach is taken. There's some historical
discussion that includes this in
https://github.com/danielfett/draft-dpop/issues/26 and maybe gives some
more insight into how it got to the way it is now.

That's not to try and say that what's been done is the one true way. But
that it's one way of many, each of which has pluses and minuses, and is
where things have coalesced.


Step 6 - HTTP methods are case-sensitive [2] so this check should also be.
>

Good point.


>
> Step 7 - It might be worth explicitly clarifying that =E2=80=9CHTTP URI=
=E2=80=9D means
> HTTPS.
>

Also a good point.


>
> Section 5:
> Can we move the definition of the DPoP header syntax (currently in sectio=
n
> 6) into its own section before here?
>

The DPoP header syntax is supposed to be defined in the preceding section
4. Will work on improving that section to make that more clear. Section 6
is about protected resource access and the new authorization header scheme
and www-authenticate challenge.



> In the last paragraph delete =E2=80=9Cby a public client":
>
>    When a DPoP-bound refresh token is used at the token endpoint by a
>    public client, the AS MUST ensure that the DPoP proof contains the
>    same public key as the one the refresh token is bound to.  The access
>    token issued MUST be bound to the public key contained in the DPoP
>    proof.
>
>
> If a DPoP-bound RT is used then the AS should verify the DPoP proof
> matches the one bound to the RT regardless of which client presented it.
> (Otherwise a confidential client could steal RTs from a public client and
> circumvent the DPoP binding).
>

Interesting, I hadn't looked at the text that way.  The "public client" was
included there more as a reminder that DPoP-bound refresh tokens would only
be issued to public clients. But I now see how you've interpreted that text
and can't unsee it. Will delete the =E2=80=9Cby a public client" there.


>
> Is it worth explicitly mentioning at some point that the AS *shouldn=E2=
=80=99t*
> try to enforce any DPoP binding at the introspection endpoint? We=E2=80=
=99ve
> actually had bugs raised from people believing that we should enforce thi=
s
> for mTLS, not realising the chicken-and-egg situation that would create.
>

I had assumed that was more or less self evident. But having bugs raised
for that suggests it's a lot less than more. So yeah, maybe such a mention
is worthwhile.



> Section 6:
> I may have missed it, but has there been any discussion of using a
> parameter on the Authorization header rather than an entirely separate
> header? For example:
>
> Authorization: DPoP at=3D=E2=80=A6,proof=3D=E2=80=A6
>
> Appendix A of RFC 7235 describes the use of token68 syntax for =E2=80=9Cl=
egacy=E2=80=9D
> authentication schemes, so I assume the authparam syntax is preferred now
> and this would avoid adding another header (but it does mean that header
> might get very large if the AT is also a JWT, potentially exceeding size
> limits in servers/proxies).
>

I don't think it happened on the mailing list but it's been among the
various approaches discussed. There's still the need for the additional
header at the token endpoint for the proof or I suppose it could be moved
into a new parameter. But, like I've said, there are trade offs with the
different approaches and, while there's nothing necessarily bad about this
one, it's not where we've mostly coalesced. Of course, we the WG could
collectively come to some rough consensus to revisit the approach. But I'm
(I hope understandably) not terribly eager to do so.


>
> (It=E2=80=99s also weird to explicitly define the syntax as token68 even =
though we
> know it's a JWT and will never contain some of those chars).
>

The token68 is for the access token, which isn't necessarily a JWT. And
token68 was intentionally keeping with RFC6750 where an access token may
contain those other characters.


>
> The example uses a JWT AT, which is needlessly confusing. I think using a
> short reference-based AT in this example would both reduce the size and
> also make clear that the DPoP proof goes in the DPoP header not the
> Authorization header.
>

The JWT AT there is the encoded version of the one whose payload is shown
in sec 7 to illustrate confirmation claim. And the jkt value is the hash of
the jwk in the DPoP proof key in the same example. So while I acknowledge
the potential confusion from two JWTs here, there was reasoning behind it.
And I want to keep it. Perhaps an additional example with a short
reference-based AT using some of the less popular toke68 chars and maybe
along with an additional example in sec 7 showing introspection.


>
> Section 7:
> As mentioned earlier, I=E2=80=99d prefer that the full JWK be included in=
 the
> =E2=80=9Ccnf=E2=80=9D rather than a hash, but if we=E2=80=99re going to u=
se a hash can we be
> explicit and use =E2=80=9Cjkt#S256=E2=80=9D please?
>

I opted to use a shorter name for the default and only hash. It's a
departure from the x5t stuff but didn't seem necessary. Some history can be
seen here https://github.com/danielfett/draft-dpop/issues/52 FWIW



> Section 8:
> Is the AS also allowed to return a WWW-Authenticate challenge with an alg=
s
> attribute if the client sends a proof with an unsupported algorithm?
>

It can't really because there's no WWW-Authenticate challenge (other than
Basic) coming from the token endpoint and it's not accepting the DPoP
authorization scheme so it would be nonsensical to challenge for one.


>
> Section 9:
> DPoP is not incompatible with TLS-based methods, and has advantages over
> them. I think the wording here should leave open the idea that you could
> actually use both.
>

Okay, we can work on the wording here towards that end. I don't think it'll
go so far as to recommend it but can reword so that it doesn't imply
incompatibility.


>
> 9.1:
> This would be a good place to mention BREACH as an example of how a DPoP
> proof (and AT) might leak, despite only being sent over a direct HTTPS
> channel. Note though that adding a random jti is an effective defence
> against this even if the server doesn=E2=80=99t check it.
>

Thanks for that note as a good reason to keep jti even if the requirements
on checking it are relaxed.


>
> 9.2:
> Maybe mention that clients should avoid reusing the same key for other
> JWTs too?
>

Maybe but it seems a bit unnecessary in this context.


>
> [1]:
> https://blog.hboeck.de/archives/900-Generating-CRIME-safe-CSRF-Tokens.htm=
l
>
> [2]: https://tools.ietf.org/html/rfc7230#section-3.1.1
>
> Cheers,
>
> Neil
>
>
> On 1 May 2020, at 20:03, Brian Campbell <
> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>
> I've pushed out a -01 revision of DPoP hopefully allowing folks enough
> time to read it before the interim meeting on Monday (apologies that it
> wasn't sooner but the edits took longer than expected or hoped). For ease
> of reference the changes in this revision are summarized below. There are=
,
> of course, still outstanding issues and discussion points that I hope to
> make some progress on during the interim meeting on Monday.
>
>    -01
>
>    *  Editorial updates
>    *  Attempt to more formally define the DPoP Authorization header
>       scheme
>    *  Define the 401/WWW-Authenticate challenge
>    *  Added "invalid_dpop_proof" error code for DPoP errors in token
>       request
>    *  Fixed up and added to the IANA section
>    *  Added "dpop_signing_alg_values_supported" authorization server
>       metadata
>    *  Moved the Acknowledgements into an Appendix and added a bunch of
>       names (best effort)
>
> ---------- Forwarded message ---------
> From: >
> Date: Fri, May 1, 2020 at 12:24 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
> To: Torsten Lodderstedt , David Waite <
> david@alkaline-solutions.com>, John Bradley , Brian
> Campbell , Daniel Fett ,
> Michael Jones 
>
>
>
> A new version of I-D, draft-ietf-oauth-dpop-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name:           draft-ietf-oauth-dpop
> Revision:       01
> Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the
> Application Layer (DPoP)
> Document date:  2020-05-01
> Group:          oauth
> Pages:          22
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop=
-01
>
> Abstract:
>    This document describes a mechanism for sender-constraining OAuth 2.0
>    tokens via a proof-of-possession mechanism on the application level.
>    This mechanism allows for the detection of replay attacks with access
>    and refresh tokens.
>
>
>
>
> 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
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

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

--000000000000ae935c05a4ecd5dc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Neil.=C2=A0 I do appreciate your r=
eview and feedback (even if it takes me a nontrivial amount of time to repl=
y). I've attempted to respond to things inline below. 

On Mon, May 4, 20=
20 at 5:51 AM Neil Madden <neil.madden@forgerock.com> wrote:
Some review comments:
<=
br>
Section 1:
I think terms like =E2=80=9Crelatively s=
imple=E2=80=9D are subjective and should be left out. I don=E2=80=99t think=
 the machinery of JWS signature verification (and associated security issue=
s) is necessarily simple at all.

That's fair. It was subjectively true to me as I wrote it but I take =
your point. 
=C2=A0

=E2=80=9Cstronger methods =E2=80=A6 =
such as [RFC8705] or [token binding]=E2=80=9D
I would dispute tha=
t these are actually stronger methods in the context of an SPA, putting asi=
de the usability issues. As has been discussed before, TLS is a shared cont=
ext in a web browser - the same TLS connection will be reused for all reque=
sts, regardless of the origin they come from. The situation is better for c=
ert-bound ATs because you need the CORS Access-Control-Allow-Credentials to=
 be set to make a cross-origin request with a client certificate, but as I =
describe below there are also other attacks against TLS that don=E2=80=99t =
apply to DPoP (and would be a good reason to adopt DPoP).=C2=A0
=


The =E2=80=9Cstronger methods" was pr=
eceded with "potentially" in hopes of toning down the strength of=
 the statement about strength somewhat. But yes it could be reworded to tak=
e away any comparative language.=C2=A0 =C2=A0 

=C2=A0
I think this section should also mention mobile use-cases, as =
IMO the case for DPoP is much stronger in those environments. Many of our c=
ustomers are looking for a PoP solution for mobile and have rejected mTLS f=
or various reasons (which have previously been discussed on this list, e.g.=
 incompatible middleboxes). DPoP is potentially really nice for these envir=
onments as they often have a nice secure element available to store the pri=
vate key and are much less susceptible to XSS and so on, but may still worr=
y about a malicious RS.

Agree t=
hat mobile/native use-cases deserve a mention. 
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
 IoT application=
s may also be a use-case as requests are often relayed over multiple hops a=
nd different transport protocols, so TLS cannot be used for end-to-end secu=
rity (although in that case you probably want a full request signing approa=
ch).

Section 2:
I think the =E2=80=9CMain =
Objective=E2=80=9D in section 2 could be improved. The vast majority of the=
 mechanisms described in the draft do nothing to address this main objectiv=
e, and are in fact intended to prevent DPoP proof replay which is relegated=
 to a =E2=80=9Csecondary objective=E2=80=9D in section 9. Only the =E2=80=
=9Chtu=E2=80=9D claim really has anything at all to do with the main object=
ive. I think some of these secondary objectives, especially the anti-replay=
 one, should be brought forward to section 2 to better justify what follows=
.

It has been mentioned several times on this list=
 that an audience restriction in the AT would also solve this main objectiv=
e, and the response has generally been that adding audience restrictions is=
 hard in practice - e.g. due to the AS not knowing where the AT is intended=
 to be used. I think it would be useful to explicitly add some discussion o=
f this, and perhaps a comparison with things like resource indicators that =
presumably could solve at least some of the issues with audience restrictio=
ns.

I think there *are* significant advantages of =
DPoP that address real-world attacks that cannot be solved in any other way=
 currently. For example, I was reading [1] recently about CRIME/BREACH atta=
cks against CSRF tokens and it occurred to me that exactly the same kind of=
 attack is a real threat to access tokens in a browser and that DPoP is an =
effective mitigation against it. To summarise, these attacks exploit vulner=
abilities in TLS when combined with compression (either in TLS itself or HT=
TP compression) and can allow an attacker to steal bearer tokens or cookies=
 after observing enough requests with the same token (and being able to inf=
luence some other content in the same request/response). One recommended mi=
tigation is to randomize tokens so that they are different on every request=
, which thwarts the attack. Although DPoP doesn=E2=80=99t directly randomiz=
e the AT the AT is useless without a DPoP proof and a unique =E2=80=9Cjti=
=E2=80=9D claim ensures that the DPoP proof is randomized and so not recove=
rable through this attack. Given that BREACH is largely unmitigated in prac=
tice, due to the usefulness of compression, adding a description of this at=
tack to the justification would IMO significantly improve the rationale for=
 DPoP.

Daniel is way way =
way more adept than I when it comes to threat and attacker modeling. He als=
o penned the original text of the draft, much of which is still present. In=
 trying not to step on his toes and also be mindful of the disparity in our=
 competency, I'm really hoping that he can do an overhaul of the threat=
 model, objectives, security considerations, etc. to address this and simil=
ar commentary in a more meaningful way. The inclusion of BREACH seems worth=
while, thanks for the pointer/suggestion. I think I'd also like to see =
some discussion of mitigations for unforeseen "stuff happens" kin=
ds of threats. Like the cloudflare parser bug of a few years ago that leake=
d data including tokens and cookies. The specifics of that sort of thing pr=
obably don't belong in a document like this. But bound tokens would be =
protected against reuse when leaked like that or via other many unforeseen =
ways.

=C2=A0

Section 3:
Th=
e second bullet point of step (B) isn=E2=80=99t clear - is it implying that=
 refresh tokens for confidential clients shouldn=E2=80=99t be DPoP-bound? M=
ust not?

The intended intent of=
 the document is that refresh tokens be=20
DPoP bound only when issued to public clients. RFC6749 already requires=20
that an AS bind refresh tokens to the client to which they were issued=20
and that confidential clients (those having established authentication=20
credentials with the AS) authenticate to the AS when presenting a=20
refresh token. Thus, refresh tokens issued to confidential clients are=20
already sender-constrained to the client and its credentials. 


Step (C) implies that only JWT-structured ATs or token introspe=
ction are supported for communicating the public key. Presumably deployers =
are free to use another secure mechanism if they wish?

Yes. That wasn't meant to imply that othe=
r mechanisms weren't possible. Rather just to highlight the cases where=
 defined interop between AS and RS is in scope of this doc. We'll look =
at rewording this so as not to imply exclusivity. 
=C2=A0

The last bullet point about requiring a DPoP proof for refresh token=
s is ambiguous about what happens in the case of confidential clients if th=
e refresh token is not DPoP-bound. Do they not supply a DPoP proof at all (=
and it reuses the original one), or must they supply a new one? Can they su=
pply a *different* DPoP proof to e.g. rotate their key pair?

I'm thinking that that bullet point=
 should be removed from this introductory part and hopefully those question=
s are or will be addressed elsewhere in the document. But the idea is that =
a client will always supply a DPoP proof in the token request and issued ac=
cess tokens are bound to the proof's public key. For a public client, i=
t has to be a proof for the same key for the duration of the refresh token =
(b/c the RT is bound). A confidential client can send a DPoP proof for a di=
fferent key to effectively rotate the key pair. 
=C2=A0
=


=

Section 4:
Maybe a forward reference to section 6 when menti=
oning the DPoP header field, as that=E2=80=99s where it is defined.

Hrm. Section 4 here is trying to=
 define the DPoP header field. I guess that needs some work/improvement in =
the document. Section 6 defines the DPoP Authorization Scheme, which is rel=
ated to but different from the header field. 
=C2=A0

4.1:
I=E2=80=99m not keen about including the full =E2=80=9Cjwk=
=E2=80=9D in every DPoP proof. It never changes for the life of the AT and =
adds considerable overhead to the size of the proof. If the RS is using tok=
en introspection (with opaque ATs) then it would be much more efficient to =
return the JWK in the token introspection response and let the RS cache tha=
t. Alternatively the AS could publish the JWK under a URL on behalf of the =
client and include a =E2=80=9Cjku=E2=80=9D header instead.

There are a number of different ways the =
various bits of information could flow. And there can be advantages/disadva=
ntages depending on other things like opaque v.s. structured ATs and cachin=
g and more. 

As such, I don't believe ther=
e's necessarily a right way to do things. But the model we've tende=
d towards here and are pretty happy with is that the proof is sent the same=
 way to both the AS and RS. And that proof contains the key to which tokens=
 can be bound or such a binding can be checked. 

=C2=A0
=

In the last paragraph, is it worth explicitly calling out t=
hings like GraphQL as not suitable for DPoP due to the fact that they reuse=
 the same URI and HTTP method for all requests?

Maybe worth mentioning but seems more like a securit=
y consideration thing. 

=C2=A0

4.2:<=
/div>
I feel like this section should contain a forward reference to se=
ction 6, otherwise it appears to suggest that verifying the signature and c=
laims is sufficient - without the crucial step of ensuring that the JWK mat=
ches the actual access token. 

I'll look to add such a reference and better explain here that ve=
rifying the signature and claims of the DPoP proof JWT is what provides (so=
me reasonable level) of assurance that the caller holds the private key cor=
responding to the public key in the proof. But not more than that on it'=
;s own. =C2=A0 
=C2=A0
The potential for implementers to get this =
wrong is another reason to prefer not including the JWK directly in the DPo=
P proof but instead have it retrieved from the access token (either as a cn=
f or from token introspection). That makes it much harder to validate a pro=
of that is unrelated to the AT.

There are a variety of different ways this particular cat could have=
 been skinned. As I mentioned previously this model where the proof is the =
same regardless of where it's used is the method of skinning that's=
 kind of emerged as the preferred. Of course there are some trade offs and =
implications with whatever approach is taken. There's some historical d=
iscussion that includes this in https://github.com/danielfett/draft-d=
pop/issues/26 and maybe gives some more insight into how it got to the =
way it is now. 

That's not to try and say =
that what's been done is the one true way. But that it's one way of=
 many, each of which has pluses and minuses, and is where things have coale=
sced. 


Step 6 - HTTP methods are case-sensitiv=
e [2] so this check should also be.

=

Good point. 
=C2=A0

Step 7 - It might be=
 worth explicitly clarifying that =E2=80=9CHTTP URI=E2=80=9D means HTTPS.

Also a good point. 
=C2=A0
=


Section 5:
Can we move the definition of=
 the DPoP header syntax (currently in section 6) into its own section befor=
e here?

The DPoP header s=
yntax is supposed to be defined in the preceding section 4. Will work on im=
proving that section to make that more clear. Section 6 is about protected =
resource access and the new authorization header scheme and www-authenticat=
e challenge. 

=C2=A0
In the last paragraph delete =
=E2=80=9Cby a public client":

   When a DPo=
P-bound refresh token is used at the token endpoint by a
   public client, the AS MUST ensure that the DPoP proof contains the
   same public key as the one the refresh token is bound to.  The access
   token issued MUST be bound to the public key contained in the DPoP
   proof.


If a DPoP-bound RT is used then the AS shou=
ld verify the DPoP proof matches the one bound to the RT regardless of whic=
h client presented it. (Otherwise a confidential client could steal RTs fro=
m a public client and circumvent the DPoP binding). 
<=
/div>

Interesting, I hadn't looked at t=
he text that way.=C2=A0 The "public client" was included there mo=
re as a reminder that DPoP-bound refresh tokens would only be issued to pub=
lic clients. But I now see how you've interpreted that text and can'=
;t unsee it. Will delete the =E2=80=9Cby a public client" there. 
<=
/div>
=C2=A0

Is it worth explicitly mentioning at some point =
that the AS *shouldn=E2=80=99t* try to enforce any DPoP binding at the intr=
ospection endpoint? We=E2=80=99ve actually had bugs raised from people beli=
eving that we should enforce this for mTLS, not realising the chicken-and-e=
gg situation that would create.

I had assumed that was more or less self evident. But having bugs ra=
ised for that suggests it's a lot less than more. So yeah, maybe such a=
 mention is worthwhile. 

=C2=A0
Section 6:
I may have missed it, but has there been any discussion of using a parame=
ter on the Authorization header rather than an entirely separate header? Fo=
r example:

Authorization: DPoP at=3D=E2=80=A6,proo=
f=3D=E2=80=A6

Appendix A of RFC 7235 describes the=
 use of token68 syntax for =E2=80=9Clegacy=E2=80=9D authentication schemes,=
 so I assume the authparam syntax is preferred now and this would avoid add=
ing another header (but it does mean that header might get very large if th=
e AT is also a JWT, potentially exceeding size limits in servers/proxies).<=
/div>

I don't think it happ=
ened on the mailing list but it's been among the various approaches dis=
cussed. There's still the need for the additional header at the token e=
ndpoint for the proof or I suppose it could be moved into a new parameter. =
But, like I've said, there are trade offs with the different approaches=
 and, while there's nothing necessarily bad about this one, it's no=
t where we've mostly coalesced. Of course, we the WG could collectively=
 come to some rough consensus to revisit the approach. But I'm (I hope =
understandably) not terribly eager to do so. 
=C2=A0

(It=E2=80=99s also weird to explicitly define the syntax as token68 even =
though we know it's a JWT and will never contain some of those chars).<=
/div>

The token68 is for the ac=
cess token, which isn't necessarily a JWT. And token68 was intentionall=
y keeping with RFC6750 where an access token may contain those other charac=
ters. 
=C2=A0

The example uses a JWT AT, which is n=
eedlessly confusing. I think using a short reference-based AT in this examp=
le would both reduce the size and also make clear that the DPoP proof goes =
in the DPoP header not the Authorization header.

The JWT AT there is the encoded version of the one =
whose payload is shown in sec 7 to illustrate confirmation claim. And the j=
kt value is the hash of the jwk in the DPoP proof key in the same example. =
So while I acknowledge the potential confusion from two JWTs here, there wa=
s reasoning behind it. And I want to keep it. Perhaps an additional example=
 with a short reference-based AT using some of the less popular toke68 char=
s and maybe along with an additional example in sec 7 showing introspection=
. 
=C2=A0

Section 7:
As mentioned earlier=
, I=E2=80=99d prefer that the full JWK be included in the =E2=80=9Ccnf=E2=
=80=9D rather than a hash, but if we=E2=80=99re going to use a hash can we =
be explicit and use =E2=80=9Cjkt#S256=E2=80=9D please?

I opted to use a shorter name for the default=
 and only hash. It's a departure from the x5t stuff but didn't seem=
 necessary. Some history can be seen here https://github.com/danielfe=
tt/draft-dpop/issues/52 FWIW 

=C2=A0
=

Section 8:=

Is the AS also allowed to return a WWW-Authenticate challenge wi=
th an algs attribute if the client sends a proof with an unsupported algori=
thm?

It can't really =
because there's no WWW-Authenticate challenge (other than Basic) coming=
 from the token endpoint and it's not accepting the DPoP authorization =
scheme so it would be nonsensical to challenge for one.
=C2=
=A0
<=
br>
Section 9:
DPoP is not incompatible with TLS-based =
methods, and has advantages over them. I think the wording here should leav=
e open the idea that you could actually use both.

Okay, we can work on the wording here towards that=
 end. I don't think it'll go so far as to recommend it but can rewo=
rd so that it doesn't imply incompatibility. 
=C2=A0

9.1:
This would be a good place to mention BREACH as an exa=
mple of how a DPoP proof (and AT) might leak, despite only being sent over =
a direct HTTPS channel. Note though that adding a random jti is an effectiv=
e defence against this even if the server doesn=E2=80=99t check it.

Thanks for that note as a good r=
eason to keep jti even if the requirements on checking it are relaxed. 
=

=C2=A0

9.2:
Maybe mention that clients shoul=
d avoid reusing the same key for other JWTs too?

Maybe but it seems a bit unnecessary in this contex=
t. 
=C2=A0


Cheers,

Neil




On 1 May 2020, at 20:03, Brian Camp=
bell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrot=
e:

I've pushed out a -01 revision o=
f DPoP hopefully allowing folks enough time to read it before the interim m=
eeting on Monday (apologies that it wasn't sooner but the edits took lo=
nger than expected or hoped). For ease of reference the changes in this rev=
ision are summarized below. There are, of course, still outstanding issues =
and discussion points that I hope to make some progress on during the inter=
im meeting on Monday.

=C2=A0=C2=A0 -01
<=
br>=C2=A0 =C2=A0* =C2=A0Editorial updates
=C2=A0 =C2=A0* =C2=A0Attempt t=
o more formally define the DPoP Authorization header
=C2=A0 =C2=A0 =C2=
=A0 scheme
=C2=A0 =C2=A0* =C2=A0Define the 401/WWW-Authenticate challeng=
e
=C2=A0 =C2=A0* =C2=A0Added "invalid_dpop_proof" error code f=
or DPoP errors in token
=C2=A0 =C2=A0 =C2=A0 request
=C2=A0 =C2=A0* =
=C2=A0Fixed up and added to the IANA section
=C2=A0 =C2=A0* =C2=A0Added =
"dpop_signing_alg_values_supported" authorization server
=C2=
=A0 =C2=A0 =C2=A0 metadata
=C2=A0 =C2=A0* =C2=A0Moved the Acknowledgemen=
ts into an Appendix and added a bunch of
=C2=A0 =C2=A0 =C2=A0 names (bes=
t effort)

---------- Forwarded message ---------
From: <inte=
rnet-drafts@ietf..org>
Date: Fri, May 1, 2020 at 12:24 PM<=
br>Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
To=
: Torsten Lodderstedt <torsten@lodderstedt.net>, David Waite <david@alkaline-solution=
s.com>, John Bradley <ve7jtb@ve7jtb.com>, Brian Campbell <bcampbell@pingidentity.com>, Daniel Fett <mail@danielfett.de>, Michael Jones <mbj@microsoft.com>


<=
br>
A new version of I-D, draft-ietf-oauth-dpop-01.txt

has been successfully submitted by Brian Campbell and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dpop

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Demonstration of Proof-o=
f-Possession at the Application Layer (DPoP)

Document date:=C2=A0 2020-05-01

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.t=
xt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http=
s://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool=
s.ietf.org/html/draft-ietf-oauth-dpop-01

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https=
://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01



Abstract:

=C2=A0 =C2=A0This document describes a mechanism for sender-constraining OA=
uth 2.0

=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application =
level.

=C2=A0 =C2=A0This mechanism allows for the detection of replay attacks with=
 access

=C2=A0 =C2=A0and refresh tokens.









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










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

<=
/div>




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000ae935c05a4ecd5dc--


From nobody Tue May  5 14:15:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BDE3A0B7E for ; Tue,  5 May 2020 14:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wec7yqhjT7V for ; Tue,  5 May 2020 14:15:42 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFB23A0B7D for ; Tue,  5 May 2020 14:15:41 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id t2so218964lfc.3 for ; Tue, 05 May 2020 14:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uXrdnhKnb9iNEuON+8OWr7At6fvUk3bba8EBaMYJj2s=; b=UX4MXoH/poRfBcSVtD74HgvldPqQX2lDxczTcRkgLSmETxr/nFIIjIeURW3kbCAEI7 qVYWZl2SIY29l0HlT8+wqLLedHG9hHbd5Bf7b/k+hsmSNXVp+GB/eb0xP6Nfo4uycGnj Y5OI1gTiYdZj5FggubnixlS9h7QDJTQess5xUw8gGEh8TrHjQQt+bW89j+CqLVpXiBqa br9mZ8Gt5S8pab9AmqEToc7i7oTbsD6RJAuDP2nUT+G2XhzpvxS/0Y9P9jOb4TDFe87R x7izO7oSsCidT3ep7UE4QdScjr96xqYWHKW+qE+j2vFNlo9GNYtRIfYTJHE2S55NLWqt wTkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uXrdnhKnb9iNEuON+8OWr7At6fvUk3bba8EBaMYJj2s=; b=e07n7d9EH1G3+Tpwb7EJDKvcozThUrmhy/nsrnV0H9xe6HMLiDVDnZgU3gYUSYN5ek WIXxoMwtCpRCxaYa9nHiTlT5l95pjtsFWmxBYGpRFEE7G+oFEuXLxHglE4YVS+Fy4Zg0 C4FrRDdtjU/qXGQhuJyFfu7xZgi6mSXdLSOfJ8E3APYD8rFgdq4E4q8tV2fm1BiiNFRK 4RLwuLnuEG9yemk1Xj7mxHHdLU/vbQBllAR+gHsAYRZ2VoHbzfCGij0iXRVNy8fYkFzv 1+NyOxKrNmZmAxiz/QSTo6z9c70MesVjeJM1sJ9EgejiblUZzdPlZ5Xgk6XF5ht6AF4r x2fQ==
X-Gm-Message-State: AGi0PuYPZin4JBe1qSmssA37bUj08qF+qzxGnRLxof8zIy/K9Ad6B8+k aJBSv2SruM19+ZWtnAlcLWaUaHksG4z4tBb7srkS+ERHZxAfroDHL2z4ZGnt73mxELCaE0+UQWF BlIe6iBrYiTKLbg==
X-Google-Smtp-Source: APiQypJtRcgUojR0edrZSS+SJPCbEOHfFgIFox5cFGHp+4ubQfU6EZzA7iUsMI7ORJt4XI6O2XWqK7RKxS0d7wFK+Dw=
X-Received: by 2002:a05:6512:308c:: with SMTP id z12mr2795489lfd.195.1588713339736;  Tue, 05 May 2020 14:15:39 -0700 (PDT)
MIME-Version: 1.0
References: <158835743733.12112.7484502726888997082@ietfa.amsl.com>  <02cb01d62311$8ce1e900$a6a5bb00$@aueb.gr>
In-Reply-To: <02cb01d62311$8ce1e900$a6a5bb00$@aueb.gr>
From: Brian Campbell 
Date: Tue, 5 May 2020 15:15:13 -0600
Message-ID: 
To: Nikos Fotiou 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000043f0e905a4ed2661"
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 21:15:48 -0000

--00000000000043f0e905a4ed2661
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, it potentially could. But I think we *really* want to avoid
adding a challenge/response
round trip to every call. So it wouldn't be a nonce exactly and there'd
need to some guidance or something on what it is and how long it could be
used. And that could introduce new server side state. Also the challenge
doesn't exist for the token endpoint.

On Tue, May 5, 2020 at 1:15 PM Nikos Fotiou  wrote:

> Hi all,
>
> There was some discussion about adding =E2=80=9Cserver contribution=E2=80=
=9D in the DPoP
> proof. I was wondering if the =E2=80=9Cchallenge=E2=80=9D server response=
 described in
> section 6 can include such a contribution (e.g., a server generated nonce=
).
>
>
>
> Best,
>
> Nikos
>
>
>
> *From:* OAuth  *On Behalf Of *Brian Campbell
> *Sent:* Friday, May 1, 2020 10:03 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Fwd: New Version Notification for
> draft-ietf-oauth-dpop-01.txt
>
>
>
> I've pushed out a -01 revision of DPoP hopefully allowing folks enough
> time to read it before the interim meeting on Monday (apologies that it
> wasn't sooner but the edits took longer than expected or hoped). For ease
> of reference the changes in this revision are summarized below. There are=
,
> of course, still outstanding issues and discussion points that I hope to
> make some progress on during the interim meeting on Monday.
>
>
>
>    -01
>
>
>    *  Editorial updates
>    *  Attempt to more formally define the DPoP Authorization header
>       scheme
>    *  Define the 401/WWW-Authenticate challenge
>    *  Added "invalid_dpop_proof" error code for DPoP errors in token
>       request
>    *  Fixed up and added to the IANA section
>    *  Added "dpop_signing_alg_values_supported" authorization server
>       metadata
>    *  Moved the Acknowledgements into an Appendix and added a bunch of
>       names (best effort)
>
>
>
> ---------- Forwarded message ---------
> From: >
> Date: Fri, May 1, 2020 at 12:24 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
> To: Torsten Lodderstedt , David Waite <
> david@alkaline-solutions.com>, John Bradley , Brian
> Campbell , Daniel Fett ,
> Michael Jones 
>
>
>
>
> A new version of I-D, draft-ietf-oauth-dpop-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name:           draft-ietf-oauth-dpop
> Revision:       01
> Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the
> Application Layer (DPoP)
> Document date:  2020-05-01
> Group:          oauth
> Pages:          22
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop=
-01
>
> Abstract:
>    This document describes a mechanism for sender-constraining OAuth 2.0
>    tokens via a proof-of-possession mechanism on the application level.
>    This mechanism allows for the detection of replay attacks with access
>    and refresh tokens.
>
>
>
>
> 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
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

--00000000000043f0e905a4ed2661
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, it potentially could. But I think we *really* wa=
nt to avoid adding a challenge/response round trip to =
every call. So it wouldn't be a nonce exactly and there'd need to s=
ome guidance or something on what it is and how long it could be used. And =
that could introduce new server side state. Also the challenge doesn't =
exist for the token endpoint.=C2=A0 

On Tue, May 5, 2020 at 1:15 PM Nikos Fotiou <fotiou@aueb.gr> wrote:
=

Hi all,=

There was some discussion a=
bout adding =E2=80=9Cserver contribution=E2=80=9D in the DPoP proof. I was =
wondering if the =E2=80=9Cchallenge=E2=80=9D server response described in s=
ection 6 can include such a contribution (e.g., a server generated nonce).<=
u>
=
=C2=A0
Best,
Nikos=

=
=C2=A0
Fro=
m: OAuth <oauth-bounces@ietf.org> On Behalf O=
f Brian Campbell
Sent: Friday, May 1, 2020 10:03 PM
To:=
 oauth <oauth@ie=
tf.org>
Subject: [OAUTH-WG] Fwd: New Version Notification =
for draft-ietf-oauth-dpop-01.txt
=C2=A0
I'v=
e pushed out a -01 revision of DPoP hopefully allowing folks enough time to=
 read it before the interim meeting on Monday (apologies that it wasn't=
 sooner but the edits took longer than expected or hoped). For ease of refe=
rence the changes in this revision are summarized below. There are, of cour=
se, still outstanding issues and discussion points that I hope to make some=
 progress on during the interim meeting on Monday.
<=
div>
=C2=A0
=C2=A0=C2=A0 -01

=C2=A0 =C2=A0* =C2=A0Editorial updates
=C2=A0 =C2=A0* =C2=A0Attem=
pt to more formally define the DPoP Authorization header
=C2=A0 =C2=A0 =
=C2=A0 scheme
=C2=A0 =C2=A0* =C2=A0Define the 401/WWW-Authenticate chall=
enge
=C2=A0 =C2=A0* =C2=A0Added "invalid_dpop_proof" error cod=
e for DPoP errors in token
=C2=A0 =C2=A0 =C2=A0 request
=C2=A0 =C2=A0=
* =C2=A0Fixed up and added to the IANA section
=C2=A0 =C2=A0* =C2=A0Adde=
d "dpop_signing_alg_values_supported" authorization server
=C2=
=A0 =C2=A0 =C2=A0 metadata
=C2=A0 =C2=A0* =C2=A0Moved the Acknowledgemen=
ts into an Appendix and added a bunch of
=C2=A0 =C2=A0 =C2=A0 names (bes=
t effort)
=C2=A0
---------- Forwarded message --------=
-
From: <internet-drafts@ietf..org>
Date: Fri, May 1, 2020 at 12:24 PMSubject: New Version Notification for draft-ietf-oauth-dpop-01.txt
To:=
 Torsten Lodderstedt <torsten@lodderstedt.net>, David Waite <david@alkaline-solution=
s.com>, John Bradley <ve7jtb@ve7jtb.com>, Brian Campbell <bcampbell@pingidentity.com>, Daniel Fett <mail@danielfett.de>, Michael Jones <mbj@microsoft.com>
<=
/div>



A new =
version of I-D, draft-ietf-oauth-dpop-01.txt
has been successfully submi=
tted by Brian Campbell and posted to the
IETF repository.

Name:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dpop
Revision:=
=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 O=
Auth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPo=
P)
Document date:=C2=A0 2020-05-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
URL:=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.or=
g/internet-drafts/draft-ietf-oauth-dpop-01.txt
Status:=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-=
oauth-dpop/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool=
s.ietf.org/html/draft-ietf-oauth-dpop-01
Htmlized:=C2=A0 =C2=A0 =C2=
=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-o=
auth-dpop
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-01
Abstract:
=C2=A0 =C2=A0This document describes a mechanism for sender-c=
onstraining OAuth 2.0
=C2=A0 =C2=A0tokens via a proof-of-possession mech=
anism on the application level.
=C2=A0 =C2=A0This mechanism allows for t=
he detection of replay attacks with access
=C2=A0 =C2=A0and refresh toke=
ns.




Please note that it may take a couple of minutes fro=
m the time of submission
until the htmlized version and diff are availab=
le at tools.ietf.org.

The IETF Secretariat


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

OAuth mailing list

OAuth@ietf.org

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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000043f0e905a4ed2661--


From nobody Tue May  5 15:52:40 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DC43A0C13 for ; Tue,  5 May 2020 15:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogPZe0VJr6Sh for ; Tue,  5 May 2020 15:52:37 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5323A0C14 for ; Tue,  5 May 2020 15:52:36 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 045MqU5D027981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 May 2020 18:52:32 -0400
Date: Tue, 5 May 2020 15:52:29 -0700
From: Benjamin Kaduk 
To: Mike Jones 
Cc: "oauth@ietf.org" , Dmitri Zagidulin 
Message-ID: <20200505225229.GW27494@kduck.mit.edu>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 22:52:38 -0000

On Fri, May 01, 2020 at 02:29:02AM +0000, Mike Jones wrote:
>   *   Is the DPoP signature really needed when requesting a bound token?  It seems like the worst that could happen would be to create a token bound to a key you don't control, which you couldn't use.  Daniel expressed concern about this enabling substitution attacks.

Substitution and confused deputy attacks, yes.  I would feel a lot better
if the signature is required when requesting the bound token; a fair bit of
extra analysis would be needed to try to remove it.

-Ben


From nobody Tue May  5 16:00:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411233A0C1F for ; Tue,  5 May 2020 16:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMQR0L7DfBKC for ; Tue,  5 May 2020 16:00:36 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8013A0C0A for ; Tue,  5 May 2020 16:00:35 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 045N0Uex030078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 May 2020 19:00:32 -0400
Date: Tue, 5 May 2020 16:00:29 -0700
From: Benjamin Kaduk 
To: Denis 
Cc: oauth@ietf.org
Message-ID: <20200505230029.GX27494@kduck.mit.edu>
References:  <27491ba3-857d-8ab9-fbe3-f3cf37d0078b@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <27491ba3-857d-8ab9-fbe3-f3cf37d0078b@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 23:00:38 -0000

Hi Denis,

On Fri, May 01, 2020 at 10:47:18AM +0200, Denis wrote:
>    Comments on draft-ietf-oauth-dpop-00.
> 
>    1) In section 9 (Security considerations), the text states:
> 
>            DPoP does not, however, achieve the
>       same level of protection as TLS-based methods such as OAuth Mutual
>       TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding]
>       (see also Section 9.1 and Section 9.4).
> 
>    draft-ietf-oauth-token-binding-08 [i.e. I-D.ietf-oauth-token-binding]
>    expired on April 22, 2019,
>    thus it does not seem adequate to refer to it.

It can still be useful to refer to technology that ended up not getting
deployed, for comparison against the work in questionn.

>    2)  The text states:
> 
>            9.1.  DPoP Proof Replay
> 
>       If an adversary is able to get hold of a DPoP proof JWT, the
>       adversary could replay that token at the same endpoint (the HTTP
>       endpoint and method are enforced via the respective claims in the
>       JWTs).
> 
>    This is true, but there is a worse case:  if a client legitimately obtains
>    a DPoP proof JWT and collaborates
>    with another client, then it can provide it to that other client.

Would we not consider one or both such clients to be "an adversary" in that
situation?  They are, after all, behaving contrary to the expected flow.

>    3)  The text states:
> 
>       9.4.  Message Integrity
> 
>       DPoP does not ensure the integrity of the payload or headers of
>       requests.  The signature of DPoP proofs only contains the HTTP URI
>       and method, but not, for example, the message body or other request
>       headers.
> 
>       This is an intentional design decision to keep DPoP simple to use,
>       but as described, makes DPoP potentially susceptible to replay
>       attacks where an attacker is able to modify message contents and
>       headers.  In many setups, the message integrity and confidentiality
>       provided by TLS is sufficient to provide a good level of protection.
> 
>    DPoP alone or DPoP used in conjunction with TLS does not provide any
>    protection in case of collusion attacks
>    between collaborative clients.

Do you think that the reader would expect such protection in the absence of
text in the security considerations section?
My personal expectation is that the reader would not expect protection
against a client that colludes with some other (malicious) party, and that
such a client would itself be deemed malicious.

Thanks,

Ben

>    Collaborative attacks between clients cannot be countered using
>    software-only implementations.
>    It should also be noticed that the use of secure elements to only protect
>    private keys is insufficient,
>    since a collaborative client can still perform all the cryptographic
>    computations needed by the other client.
> 
>    These considerations about collaborative clients should be added into the
>    security considerations section.
> 
>    Denis


From nobody Wed May  6 10:48:40 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8714F3A00D2 for ; Wed,  6 May 2020 10:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.994
X-Spam-Level: 
X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vYUoKLSKDkO for ; Wed,  6 May 2020 10:48:37 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C613A0947 for ; Wed,  6 May 2020 10:48:36 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id a21so3292234ljj.11 for ; Wed, 06 May 2020 10:48:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=VYZF2fDqPbh/acr8mfK5nO9cEkdx7dcctH7r36C/HEo=; b=C1l6pwcVJg+fToxMsw6WsuP5uVMeWMiOb0b8guPfkNaBQZIVaLiCg+P5mFwFwdc9bO xmrdXEfHM3197uaGsl7FhvIjFt3Bt4N/ZTdtKp7FkcKVkdIaEcDgtvJptICYx23dZWK3 2V9aiq/8Yy/7mr9ZE4mteUtKG7E7BqHNfGIv8IqBEIsBKBHPm5JpKo2ZIbrosBaa63WL 0tffkCrRod+wgzX14Xb7olzvFS7s/m4PiTTj2xztWsPAnu6PWHpNyrBLoeNggSd7pu8j XaSgbbV/o9o0p+BKLC63J7/9ebObKshUgSp2nyEMbtKqXO/YO9q4KmL5Uuf0hXE0h7l9 FscA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VYZF2fDqPbh/acr8mfK5nO9cEkdx7dcctH7r36C/HEo=; b=TlLfKpb/9ClRJVErmgfRzATFRS4W8cdHXDhEv/BtVcKejyNbk2Tmj71ZxogXMQootw 6Y2W5JKi1ECjGav01Cd1Sju/LuyD/jqhTmucMr/Qnx33rC3onDHAKni5408OhHgWYxWz iYFGszngU5ekO/20AZ9ZucNEoiBpZXIEhMXIKfsE4WXcwnqc5l95BWD9NPgTEvC0hh/+ NX51fDm8yi8ROLsiPjjfjYqfYFwe+K8Crn9vI05C06ls5cN22xboFFFT8zx7QAaCRmHt bVOHpRZrMYP8Vm6ZuIw8pP1Ou2B4H/I1d3GxqQsqZtP893dzoS3UhdNeaL88nraUmI1H l/dQ==
X-Gm-Message-State: AGi0PuaYV4/MxLy4eKE7rSdAZJQ6kr9rsqYZfoaZvQjDcV48OOVjPL68 O+/6gtquw05a8sHCadJV4bh3Ws6X8sgAL1u8YI5yUuSMwkk=
X-Google-Smtp-Source: APiQypJuc71xtM+8wmgY+PVJQltN80QoXUEsBWTz193bvUmPV86pwAjh0rVTviUWMrgewBsw9ekKwXEcDVMtllnHijQ=
X-Received: by 2002:a2e:b1c9:: with SMTP id e9mr5983035lja.102.1588787314456;  Wed, 06 May 2020 10:48:34 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Wed, 6 May 2020 10:48:08 -0700
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008080ea05a4fe5ff6"
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 17:48:39 -0000

--0000000000008080ea05a4fe5ff6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello!

We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best
practice for OAuth 2.0. It is not common in OpenID Connect servers as the
nonce solves some of the issues that PKCE protects against. We think that
most OpenID Connect implementations also support OAuth 2.0, and hence have
support for PKCE if following best practices.

The advantages or requiring PKCE are:

- a simpler programming model across all OAuth applications and profiles as
they all use PKCE

- reduced attack surface when using  S256 as a fingerprint of the verifier
is sent through the browser instead of the clear text value

- enforcement by AS not client - makes it easier to handle for client
developers and AS can ensure the check is conducted

What are disadvantages besides the potential impact to OpenID Connect
deployments? How significant is that impact?

Dick, Aaron, and Torsten

=E1=90=A7

--0000000000008080ea05a4fe5ff6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello!

We would like t=
o have PKCE be a MUST in OAuth 2.1 code flows. This is best practice for OA=
uth 2.0. It is not common in OpenID Connect servers as the nonce solves som=
e of the issues that PKCE protects against. We think that most OpenID Conne=
ct implementations also support OAuth 2.0, and hence=C2=A0have support for =
PKCE if following best practices.

The advantages o=
r requiring PKCE are:

- a simpler programming mode=
l across all OAuth applications and profiles as they all use PKCE

- reduced attack surface when using=C2=A0 S256 as a fingerp=
rint of the verifier is sent through the browser instead of the clear text =
value

- enforcement by AS not client - makes it ea=
sier to handle for client developers and AS can ensure the check is conduct=
ed

What are disadvantages besides the potentia=
l impact to OpenID Connect deployments? How significant is that impact?

Dick, Aaron, and Torsten

3D""=E1=90=A7


--0000000000008080ea05a4fe5ff6--


From nobody Wed May  6 11:21:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C93A09F8 for ; Wed,  6 May 2020 11:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz7KmejfsISH for ; Wed,  6 May 2020 11:21:35 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640103.outbound.protection.outlook.com [40.107.64.103]) (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 2AA093A09F3 for ; Wed,  6 May 2020 11:21:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EI1VuSk7PyKyJntKxKNi21ucgPMJny15Wdo3Aslva5XFeeqoKT/gUiRpXAWxi0g+xb+i7QQNqYbTwcEtCYFUvKzv99oJUB9rHgK7kHi0d9Md5SY5/bh4bvZ9TexDAQe69rJcjdkuCwTU0lefMqvVu/yXxh4qNMX7bilD20RN48S5SoH6QoIWI9BH86+IoO7Hl2t5npBsCTdw0P5wvpydhFXRPfY/P+r8n+k6U0gUV1s8TvSsF17IZNCCarUV1B88a/vvZGg8dpHSqHL/5XH6rvttRUV9t8lyqvVxdsPxfGfgzO7AVmNbMS83p9cf+0m36EhtXgetJE/UTQ/iyN83Ag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBCiZKp192fEy/NXbjBTV6yHBz22P2QpncIarfHJn8g=; b=LBooBmCll/VYkEFQZlqXxBfE9hyrVn8x56BAPx1VHuKeS/rFzew30ttYQK4ORcXCe03fyhJsLbJEWVlWhdbONjg6miUoQRQS5h/6kqlVGv80S2t28DiIsFdJy2cxgPBMR0zYu5m4RhVX/hkNVMrecbyroN255P6m3KtrPg2JkhQ4KgmWTkDnDOqARLgk14EG8xnTEfn5l9ewQkHI4S9QPYPqs3yExRXE6BmfWLZBm7gEBF2b6wF9NltDafUoepDKLniFRBTR0rmd5LjVQI+HeP+oNOBq+1Vf365xKIMCC+034XuG+u9gFBCBgAzyzZekAIpa6prFA3wUFGoOFRthdg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBCiZKp192fEy/NXbjBTV6yHBz22P2QpncIarfHJn8g=; b=ASxTuWt7RgzedkF6cUN38FXPy457XNtqVJPdOd5XxOxAxTgpkqRm4H/y+kBGRPXfgqvMY9yhbVbZ4WvQiGRs1GW0N9EhuiNg0E9IEnxZyKzkCCRJHU4dmCOePPcFqriy/6kcjIczYTCMNRLb0JrgXqoevNz0apoiGa1bvezSTTI=
Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0666.namprd00.prod.outlook.com (2603:10b6:5:220::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3019.0; Wed, 6 May 2020 18:21:19 +0000
Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b%5]) with mapi id 15.20.3015.000; Wed, 6 May 2020 18:21:19 +0000
From: Mike Jones 
To: Dick Hardt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYj0yIsbYPLqhhfTlu3+dAH+R+3ug==
Date: Wed, 6 May 2020 18:21:19 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5a379c11-bf0d-4664-918a-00006542b4d5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T17:58:47Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c78f096d-ff22-4602-6033-08d7f1ea45f0
x-ms-traffictypediagnostic: DM6PR00MB0666:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: m8yjVqYkcVrvvAz1aPduYW6q5SI+fY50XdoH7eOqKvZYCH4unKW5uFvMQM7tvVsnXEnCcogcNZZoUjYaBZD6TGpohwgb8YI8KdyhxAfgyj+Sr/oXkbwi0FL0d7dGmN+9crWH2BKlatZ3sMqXrnLU2i+LoHommPF4MWXQJ1rQFiVeELDKdbZlanVrieUve4Huv7FXFvX3jaWlE+z7tL3pEznkWNYcBqyyPRY1YlcM0G9ItXuo6JxFrmgI1QDql/QkAxadCfrcAhms75R58MMyMki2um2dp/0dCNwZ/lpb5aOpQ4hAM8qo1/ylZ9vFstA+B+rJz83OwrJ8nj8YaFG5XH4aLSWMp8NfAXTjw95Dt+VkJmJz9MQ18hT4d6cl1LlMTvNhk6GN+QSD720Izw1G/vIQ+8VjDHoKvUNUfoKz4aWAEu1/eFWjwo1IP1+2XN/b3HlUNlNOl2UW5bopQ+PNQSFATJIH60yAjykaWTz7Y/45nCXHrF8nQTmM81BCFdJGBwTzaSgKOETwoaIEvSluuw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(346002)(376002)(39860400002)(136003)(366004)(33430700001)(478600001)(33656002)(10290500003)(110136005)(5660300002)(8676002)(66476007)(66556008)(64756008)(66446008)(8990500004)(966005)(8936002)(53546011)(55016002)(66946007)(86362001)(6506007)(52536014)(26005)(33440700001)(66574014)(166002)(186003)(7696005)(2906002)(82950400001)(82960400001)(316002)(9686003)(76116006)(71200400001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: UEt8EqekFr0T48E0Fdlq3xH4dky50pwKXmnDADy1xVDGkYnG69ty6mvkLzoZOrUxqecKM7KcRYCiy6wnUMo9osSXbpezr9mwJV3uY77vpCcFoHLpNLkvJKyIExc3pHVCfSSZpmmimxW76mKFJnYt67zPijgacEGIj8s7oBKRUyxFCzR370eiGlKGwJfzOHFBLSkXkAgeS4Mv5yiOgVIXIn+n+IJQ2kWoi26gTiTZrC2M798CZIV88dgngCnrB5P+QJ866vqW/89YcovZqzdRTlWrOcvTkwFn1dfJ+iOMygEH46ikINm0XWFrzltaxDRO8Rmb31CZl3E4AOQFy3Cjnz379lparHXoghotI1vNe1+VI/CcciT66ofWb1Zx8WJ9S9lMRfjj0RPGXL/yCTMszmkcBjhLFvtK7a8pOHlfDkLKFzvJb/cqrCyCm4RCRsUQhHsnZFPizDjDPvcCA49wrabtzgQFxYp3S3mE+3sI93u2sMtq9XD43sl3hLc7MCxhlO6cbKKvGRc/Xw0WGXHp3CdAz9oCWgKYbXs4Ng4J5eBjQnEcwF/hdDV3SpOVhPtlH5IxYeak2AtUga7wF1diLq7Ee0KtL5PSIKuJ+mLM5eNRwU+2kRJ03SjRAKV7A9rp5h+9Lfsh2rYd73ewaWGXDxHgCn4G7xrEI47Z3Sltotbs2/f5Qa5nlP7AjKc67NU3TxdnzfbqBZ4lp8iKZkHKoSrHxGZhbbzdVBfwc6Gyt2R5isJeqA7KlCq+xU//Lbfq04duNliLxz4TOSM55ipnwobAv/CTg2y8lcINGH3MPzE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB068479502D207D9F2C8F1031F5A40DM6PR00MB0684namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c78f096d-ff22-4602-6033-08d7f1ea45f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 18:21:19.2833 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ig1rzLtcGk0GoeDvgiE74HDpvAYSxrB/g5zklYAFAjkYwUeJ7mnQm6xpchA8Ck5LZYcRJ82a/lpHkK9f54Nzbw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0666
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 18:21:37 -0000

--_000_DM6PR00MB068479502D207D9F2C8F1031F5A40DM6PR00MB0684namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGRpc2FkdmFudGFnZSBvZiByZXF1aXJpbmcgUEtDRSBmb3IgT3BlbklEIENvbm5lY3QgaW1w
bGVtZW50YXRpb25zIGlzIHRoYXQgeW914oCZcmUgdHJ5aW5nIHRvIGFkZCBhIG5vcm1hdGl2ZSBy
ZXF1aXJlbWVudCB0aGF04oCZcyBub3QgcmVxdWlyZWQgb2YgT3BlbklEIENvbm5lY3QgZGVwbG95
bWVudHMgdG9kYXksIHdoaWNoIHdvdWxkIGJpZnVyY2F0ZSB0aGUgZWNvc3lzdGVtLiAgVGhlcmUg
YXJlIGh1bmRyZWRzIG9mIGltcGxlbWVudGF0aW9ucyAoaW5jbHVkaW5nIHRoZSAxNDEgY2VydGlm
aWVkIG9uZXMgYXQgaHR0cHM6Ly9vcGVuaWQubmV0L2NlcnRpZmljYXRpb24vKSwgbm9uZSBvZiB3
aGljaCBoYXZlIGV2ZXIgYmVlbiByZXF1aXJlZCB0byBzdXBwb3J0IFBLQ0UuICBUaGVyZWZvcmUs
IG1vc3QgZG9u4oCZdC4NCg0KUGVyIGZlZWRiYWNrIGFscmVhZHkgcHJvdmlkZWQsIEkgYmVsaWV2
ZSB0aGF0IE9BdXRoIDIuMSBzaG91bGQgYWxpZ24gd2l0aCB0aGUgZ3VpZGFuY2UgYWxyZWFkeSBp
biB0aGUgZHJhZnQgU2VjdXJpdHkgQkNQLCByZXF1aXJpbmcgRUlUSEVSIHRoZSB1c2Ugb2YgUEtD
RSBvciB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuICBUcnlpbmcgdG8gcmV0cm9hY3RpdmVseSBp
bXBvc2UgdW5uZWNlc3NhcnkgcmVxdWlyZW1lbnRzIG9uIGV4aXN0aW5nIGRlcGxveW1lbnRzIGlz
IHVubGlrZWx5IHRvIHN1Y2NlZWQgYW5kIHdpbGwgc2lnbmlmaWNhbnRseSByZWR1Y2UgdGhlIHJl
bGV2YW5jZSBvZiB0aGUgT0F1dGggMi4xIGVmZm9ydC4NCg0KSW4gcGFydGljdWxhciwgYXV0aG9y
aXphdGlvbiBzZXJ2ZXJzIHNob3VsZG7igJl0IGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3
aGVuIHRoZXkgYWxyZWFkeSBzdXBwb3J0IHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4gIEFuZCBj
bGllbnRzIHNob3VsZG7igJl0IHJlamVjdCByZXNwb25zZXMgZnJvbSBzZXJ2ZXJzIHRoYXQgZG9u
4oCZdCBzdXBwb3J0IFBLQ0Ugd2hlbiB0aGV5IGRvIGNvbnRhaW4gdGhlIE9wZW5JRCBDb25uZWN0
IG5vbmNlLiAgRG9pbmcgc28gd291bGQgdW5uZWNlc3NhcmlseSBicmVhayB0aGluZ3MgYW5kIGNy
ZWF0ZSBjb25mdXNpb24gaW4gdGhlIG1hcmtldHBsYWNlLg0KDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBP
QXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNl
bnQ6IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAgMTA6NDggQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0K
U3ViamVjdDogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/DQoNCkhlbGxvIQ0K
DQpXZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUg
Zmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29t
bW9uIGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9m
IHRoZSBpc3N1ZXMgdGhhdCBQS0NFIHByb3RlY3RzIGFnYWluc3QuIFdlIHRoaW5rIHRoYXQgbW9z
dCBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBzdXBwb3J0IE9BdXRoIDIuMCwg
YW5kIGhlbmNlIGhhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGlj
ZXMuDQoNClRoZSBhZHZhbnRhZ2VzIG9yIHJlcXVpcmluZyBQS0NFIGFyZToNCg0KLSBhIHNpbXBs
ZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHBy
b2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NFDQoNCi0gcmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3
aGVuIHVzaW5nICBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlmaWVyIGlzIHNlbnQg
dGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZhbHVlDQoNCi0g
ZW5mb3JjZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUg
Zm9yIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25k
dWN0ZWQNCg0KV2hhdCBhcmUgZGlzYWR2YW50YWdlcyBiZXNpZGVzIHRoZSBwb3RlbnRpYWwgaW1w
YWN0IHRvIE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlmaWNhbnQgaXMgdGhh
dCBpbXBhY3Q/DQoNCkRpY2ssIEFhcm9uLCBhbmQgVG9yc3Rlbg0KDQpbaHR0cHM6Ly9tYWlsZm9v
Z2FlLi5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNE
JnR5cGU9emVyb2NvbnRlbnQmZ3VpZD00NTI0MzhiYS1kNDI5LTQ2NTYtYWNlOS1iMjg0NzQ0YmMx
NzFd4ZCnDQo=

--_000_DM6PR00MB068479502D207D9F2C8F1031F5A40DM6PR00MB0684namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv
cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk
aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o
ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlIGRpc2FkdmFudGFnZSBvZiByZXF1aXJpbmcgUEtDRSBm
b3IgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGlzIHRoYXQgeW914oCZcmUgdHJ5aW5n
IHRvIGFkZCBhIG5vcm1hdGl2ZSByZXF1aXJlbWVudCB0aGF04oCZcyBub3QgcmVxdWlyZWQgb2Yg
T3BlbklEIENvbm5lY3QgZGVwbG95bWVudHMgdG9kYXksIHdoaWNoIHdvdWxkIGJpZnVyY2F0ZSB0
aGUgZWNvc3lzdGVtLiZuYnNwOw0KIFRoZXJlIGFyZSBodW5kcmVkcyBvZiBpbXBsZW1lbnRhdGlv
bnMgKGluY2x1ZGluZyB0aGUgMTQxIGNlcnRpZmllZCBvbmVzIGF0IDxhIGhyZWY9Imh0dHBzOi8v
b3BlbmlkLm5ldC9jZXJ0aWZpY2F0aW9uLyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MDt0
ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9vcGVuaWQubmV0L2NlcnRpZmljYXRpb24vPC9z
cGFuPjwvYT4pLCBub25lIG9mIHdoaWNoIGhhdmUgZXZlciBiZWVuIHJlcXVpcmVkIHRvIHN1cHBv
cnQgUEtDRS4mbmJzcDsgVGhlcmVmb3JlLCBtb3N0IGRvbuKAmXQuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDAyMDYwIj5QZXIgZmVlZGJhY2sgYWxyZWFkeSBwcm92aWRlZCwgSSBiZWxp
ZXZlIHRoYXQgT0F1dGggMi4xIHNob3VsZCBhbGlnbiB3aXRoIHRoZSBndWlkYW5jZSBhbHJlYWR5
IGluIHRoZSBkcmFmdCBTZWN1cml0eSBCQ1AsIHJlcXVpcmluZyBFSVRIRVIgdGhlIHVzZSBvZiBQ
S0NFIG9yIHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4mbmJzcDsgVHJ5aW5nIHRvIHJldHJvYWN0
aXZlbHkNCiBpbXBvc2UgdW5uZWNlc3NhcnkgcmVxdWlyZW1lbnRzIG9uIGV4aXN0aW5nIGRlcGxv
eW1lbnRzIGlzIHVubGlrZWx5IHRvIHN1Y2NlZWQgYW5kIHdpbGwgc2lnbmlmaWNhbnRseSByZWR1
Y2UgdGhlIHJlbGV2YW5jZSBvZiB0aGUgT0F1dGggMi4xIGVmZm9ydC48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwMDIwNjAiPkluIHBhcnRpY3VsYXIsIGF1dGhvcml6YXRpb24gc2VydmVy
cyBzaG91bGRu4oCZdCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IFBLQ0Ugd2hlbiB0aGV5IGFscmVh
ZHkgc3VwcG9ydCB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5ic3A7IEFuZCBjbGllbnRzIHNo
b3VsZG7igJl0IHJlamVjdCByZXNwb25zZXMgZnJvbSBzZXJ2ZXJzIHRoYXQgZG9u4oCZdCBzdXBw
b3J0IFBLQ0Ugd2hlbg0KIHRoZXkgZG8gY29udGFpbiB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2Uu
Jm5ic3A7IERvaW5nIHNvIHdvdWxkIHVubmVjZXNzYXJpbHkgYnJlYWsgdGhpbmdzIGFuZCBjcmVh
dGUgY29uZnVzaW9uIGluIHRoZSBtYXJrZXRwbGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24g
QmVoYWxmIE9mIDwvYj4NCkRpY2sgSGFyZHQ8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBN
YXkgNiwgMjAyMCAxMDo0OCBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyE8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdvdWxkIGxpa2UgdG8gaGF2
ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29kZSBmbG93cy4gVGhpcyBpcyBiZXN0IHBy
YWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBjb21tb24gaW4gT3BlbklEIENvbm5lY3Qg
c2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUgb2YgdGhlIGlzc3VlcyB0aGF0IFBLQ0Ug
cHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsgdGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0DQogaW1w
bGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBoZW5jZSZuYnNwO2hhdmUg
c3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhZHZhbnRhZ2Vz
IG9yIHJlcXVpcmluZyBQS0NFIGFyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3Nz
IGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NF
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g
cmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3aGVuIHVzaW5nJm5ic3A7IFMyNTYgYXMgYSBmaW5nZXJw
cmludCBvZiB0aGUgdmVyaWZpZXIgaXMgc2VudCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQg
b2YgdGhlIGNsZWFyIHRleHQgdmFsdWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBlbmZvcmNlbWVudCBieSBBUyBub3QgY2xpZW50IC0gbWFr
ZXMgaXQgZWFzaWVyIHRvIGhhbmRsZSBmb3IgY2xpZW50IGRldmVsb3BlcnMgYW5kIEFTIGNhbiBl
bnN1cmUgdGhlIGNoZWNrIGlzIGNvbmR1Y3RlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMg
dGhlIHBvdGVudGlhbCBpbXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBz
aWduaWZpY2FudCBpcyB0aGF0IGltcGFjdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGljaywgQWFyb24sIGFuZCBUb3JzdGVuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxm
b29nYWUuLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAl
M0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9NDUyNDM4YmEtZDQyOS00NjU2LWFjZTkt
YjI4NDc0NGJjMTcxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_DM6PR00MB068479502D207D9F2C8F1031F5A40DM6PR00MB0684namp_--


From nobody Wed May  6 11:57:08 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8263A0AA0 for ; Wed,  6 May 2020 11:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMUeV4OItfm1 for ; Wed,  6 May 2020 11:56:08 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0867E3A0A9F for ; Wed,  6 May 2020 11:56:07 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id c18so2814060ile.5 for ; Wed, 06 May 2020 11:56:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7dtHTPbSB5fC1R08vVv7VSoLykjNN88hUEZPsud0Arg=; b=s8JCJhrY/Cs5dmNn6UzqLs8k3EjkxZniVzx0VianKnYTK4ymmeSHkmFb3uWwBzx0Pg rSoWe4FKl3DhUoI25mNrGRKVZjSg2xJLrb5S+027Ds1NNUIqXknBxbEl9zoFiqkf0yM1 i/k4V9xt/oaUw4SYm0jWvCzEP/BJEAtU67AUeTxUrADHffC1XfrDSNlzSisFv/d5mOan 2+zozmGpbz4AMLMWCtw31/sQZomD1FxRmZXpeAJ0Yk0YEGRHATvnq7kj9WZ/ydQT8oYh Vwm+k4YITc3Euzbpd3mBJqr/F56J9M5H+fqXz9t9f2MmxN7zjKIr+pcAaQbSmTFCPzmY HlJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7dtHTPbSB5fC1R08vVv7VSoLykjNN88hUEZPsud0Arg=; b=bh/btgDp3f5roqs/479MA0I0rBQifData2YpFinJDLT9uwSQv/9kfOdkNAOIfWSZg2 gOAJKi6sMd0fLfXyqJYQaTrNMtzyaKnuNKuthRbQMPBmumhByRDXFI+axxksKrwLCq7u nOjPZWi+d+tgZRmVjxtWQ/37vpKbqYmI4QVmmT/YY4Q631ErKJZ40GIaCYv08epj8Ylc P8m+I/aoBY6ZoHHt9S/hkv6s4NekLwnSeZ4l2DFqj/66k3W4kStOQ1I3O0dGwGpv36++ zbIRLKpNjkxKCCjGFHMsgZma7nzNFMab1rkzms9epiuOIVsn+cNmUFwPwsSb5j0aIJoT US7g==
X-Gm-Message-State: AGi0PubF6DfLSe1juZ9rn4VZY7JdAbFWEmlp5Ln06uC6raRt4W0bX8yh egoTUjoUusetUO+bQ/KmNbDzRD1Y2Ro=
X-Google-Smtp-Source: APiQypI3fmbPZEsOzuGGpZ8TubTGDYZzSEf1cuCwv5bkeFoJ2gdgNr1yq5lfGRcyG6hBMGZYHdA6KA==
X-Received: by 2002:a92:280d:: with SMTP id l13mr10603500ilf.109.1588791366063;  Wed, 06 May 2020 11:56:06 -0700 (PDT)
Received: from mail-il1-f170.google.com (mail-il1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id m7sm1427301ioq.33.2020.05.06.11.56.04 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 11:56:05 -0700 (PDT)
Received: by mail-il1-f170.google.com with SMTP id m5so431056ilj.10 for ; Wed, 06 May 2020 11:56:04 -0700 (PDT)
X-Received: by 2002:a92:2912:: with SMTP id l18mr10546404ilg.28.1588791364688;  Wed, 06 May 2020 11:56:04 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 6 May 2020 11:55:53 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Mike Jones 
Cc: Dick Hardt , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000ea217505a4ff5013"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 18:56:12 -0000

--000000000000ea217505a4ff5013
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> In particular, authorization servers shouldn=E2=80=99t be required to sup=
port
PKCE when they already support the OpenID Connect nonce.

The Security BCP already requires that ASs support PKCE:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1=
.1
Are
you suggesting that the Security BCP change that requirement as well? If
so, that's a discussion that needs to be had ASAP. If not, then that's an
implicit statement that it's okay for OpenID Connect implementations to not
be best-practice OAuth implementations. And if that's the case, then I also
think it's acceptable that they are not complete OAuth 2.1 implementations
either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones  wrote:

> The disadvantage of requiring PKCE for OpenID Connect implementations is
> that you=E2=80=99re trying to add a normative requirement that=E2=80=99s =
not required of
> OpenID Connect deployments today, which would bifurcate the ecosystem.
> There are hundreds of implementations (including the 141 certified ones a=
t
> https://openid.net/certification/), none of which have ever been required
> to support PKCE.  Therefore, most don=E2=80=99t.
>
>
>
> Per feedback already provided, I believe that OAuth 2.1 should align with
> the guidance already in the draft Security BCP, requiring EITHER the use =
of
> PKCE or the OpenID Connect nonce.  Trying to retroactively impose
> unnecessary requirements on existing deployments is unlikely to succeed a=
nd
> will significantly reduce the relevance of the OAuth 2.1 effort.
>
>
>
> In particular, authorization servers shouldn=E2=80=99t be required to sup=
port PKCE
> when they already support the OpenID Connect nonce.  And clients shouldn=
=E2=80=99t
> reject responses from servers that don=E2=80=99t support PKCE when they d=
o contain
> the OpenID Connect nonce.  Doing so would unnecessarily break things and
> create confusion in the marketplace.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Dick Hardt
> *Sent:* Wednesday, May 6, 2020 10:48 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000ea217505a4ff5013
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> In particular, authorization servers shouldn=E2=
=80=99t be required to support PKCE when they already support the OpenID Co=
nnect nonce.

The Security BCP already requires=
 that ASs support PKCE:=C2=A0https://tools.ietf.org/html/dra=
ft-ietf-oauth-security-topics-15#section-2.1.1=C2=A0Are you suggesting =
that the Security BCP change that requirement as well? If so, that's a =
discussion that needs to be had ASAP. If not, then that's an implicit s=
tatement that it's okay for OpenID Connect implementations to not be be=
st-practice OAuth implementations. And if that's the case, then I also =
think it's acceptable that they are not complete OAuth 2.1 implementati=
ons either.





<=
/div>

On Wed, May 6, 2020 at 11:21 AM Mike Jones <Michael.Jon=
es=3D40microsoft.com@dmar=
c.ietf.org> wrote:











The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D Connect deployments today, which would bifurcate the ecosystem.=C2=A0
 There are hundreds of implementations (including the 141 certified ones at=
 
https://openid.net/=
certification/), none of which have ever been required to suppor=
t PKCE.=C2=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of PKCE or the OpenI=
D Connect nonce.=C2=A0 Trying to retroactively
 impose unnecessary requirements on existing deployments is unlikely to suc=
ceed and will significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t reject responses from servers that don=E2=80=99t support PKCE when
 they do contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessari=
ly break things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of 
Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues that PKCE protects ag=
ainst. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence=C2=A0have support for PK=
CE if following best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000ea217505a4ff5013--


From nobody Wed May  6 12:12:00 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7FB3A0AA5 for ; Wed,  6 May 2020 12:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwjEMklorutk for ; Wed,  6 May 2020 12:11:57 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CE83A0AA7 for ; Wed,  6 May 2020 12:11:56 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id j21so1545670pgb.7 for ; Wed, 06 May 2020 12:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=K+b0e1ol7jiEt91qxasQHPdwKFxa8glfZyOcAI2xXWU=; b=LLxrpvrcRxrCfumpflui1VxQIVK2Wp5ix0t82MpPr3ejE/yrBsY9nHmlpAM301hJvg yjIkrieUFD83QpsZdDjTKJ0muezUPaMcNzFwKw8IyL+eeDlyvcF/+Lpx1WWZJGliX08B RQnmSu+ucnpmigNCJN/XgjL3jcOQEJTobRFnAsYX7OIK9tpzfmo0XojStn6Owm1FoaAg hU55NpEE/qmNtrZz2Kkb6WD/LU2KUgpShEKA9T0fdBMplNyumcOd+7jIxkJ+UxecS+ae lz51ALuP74cpqmlaz0CYJCgkI+1grY/L7bPo/4hnuci9zDirc+fnOsbi1HVCmjQRKjf/ LlKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=K+b0e1ol7jiEt91qxasQHPdwKFxa8glfZyOcAI2xXWU=; b=J3vHVeQU0kyX/hPLY3DIKSY7CN+Mk9p+FVMUMKG+k621o8rLrj5X17R0BcnWpc7doV UHo7yUrVHJn2J/yDaLKfqrjDGMJhDiZLQzrI61hK/RTP+TlsFOuBzxFzfPJeEQbMHtrw TSc9f0ni1ImRxNkm7qePKalIj2VDfrEiiikfKjMw6hry9tBRrcDJwFHyu412DVtHE1iD t95G9h4NJBanA1BK1NjBzIUHrjcd4XW7ITXp/xmTd2zQSBCWwm6OFKkx7el4OJPmk3Hy tnbkn4pOq4zuqS0f4ApVeY6DTF3eKs3C2jFFPG82T5RLsVE6XXPSTjoeycDGaKfyb9HG 9Qog==
X-Gm-Message-State: AGi0PuYKBTXRRgDd8+OSgAG2mLAuPbf1hfonWjy7OtbXCizymrlu/2YN WuV8TtcW7CUujOxG10ZIHr6pbCxtgvs=
X-Google-Smtp-Source: APiQypI4mibRr5AnoHPrUlOeTNym1CQdkcmyjv/ujzetR8hW0m//bzHJ8l3CAvhLrLsbwJIk7LEeEQ==
X-Received: by 2002:a62:6d03:: with SMTP id i3mr9516986pfc.249.1588792316142;  Wed, 06 May 2020 12:11:56 -0700 (PDT)
Received: from ?IPv6:2605:8d80:447:361e:9465:924b:46dc:1f70? ([2605:8d80:447:361e:9465:924b:46dc:1f70]) by smtp.gmail.com with ESMTPSA id p66sm2565694pfb.65.2020.05.06.12.11.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 12:11:55 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-7FC3F358-FE4C-470E-BBD7-7A9DB8CE3631
Content-Transfer-Encoding: 7bit
From: Phillip Hunt 
Mime-Version: 1.0 (1.0)
Date: Wed, 6 May 2020 12:11:52 -0700
Message-Id: 
References: 
Cc: Mike Jones , "oauth@ietf.org" 
In-Reply-To: 
To: Aaron Parecki 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:11:59 -0000

--Apple-Mail-7FC3F358-FE4C-470E-BBD7-7A9DB8CE3631
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Mike,

The point of 2.1 is to raise the security bar.=20

Yes it adds new MUST requirements.=20

But what about OIDC would break other than required implementation of PKCE t=
o support 2.1?

Eg Would additional signaling be required to facilitate interoperability and=
 migration between versions? Would that be an oauth issue or an OIDC one?

Phil

> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>=20
> =EF=BB=BF
> > In particular, authorization servers shouldn=E2=80=99t be required to su=
pport PKCE when they already support the OpenID Connect nonce.
>=20
> The Security BCP already requires that ASs support PKCE: https://tools.iet=
f.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 Are you suggest=
ing that the Security BCP change that requirement as well? If so, that's a d=
iscussion that needs to be had ASAP. If not, then that's an implicit stateme=
nt that it's okay for OpenID Connect implementations to not be best-practice=
 OAuth implementations. And if that's the case, then I also think it's accep=
table that they are not complete OAuth 2.1 implementations either.
>=20
>=20
>=20
>=20
>=20
>=20
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones  wrote:
>> The disadvantage of requiring PKCE for OpenID Connect implementations is t=
hat you=E2=80=99re trying to add a normative requirement that=E2=80=99s not r=
equired of OpenID Connect deployments today, which would bifurcate the ecosy=
stem.  There are hundreds of implementations (including the 141 certified on=
es at https://openid.net/certification/), none of which have ever been requi=
red to support PKCE.  Therefore, most don=E2=80=99t.
>>=20
>> =20
>>=20
>> Per feedback already provided, I believe that OAuth 2.1 should align with=
 the guidance already in the draft Security BCP, requiring EITHER the use of=
 PKCE or the OpenID Connect nonce.  Trying to retroactively impose unnecessa=
ry requirements on existing deployments is unlikely to succeed and will sign=
ificantly reduce the relevance of the OAuth 2.1 effort.
>>=20
>> =20
>>=20
>> In particular, authorization servers shouldn=E2=80=99t be required to sup=
port PKCE when they already support the OpenID Connect nonce.  And clients s=
houldn=E2=80=99t reject responses from servers that don=E2=80=99t support PK=
CE when they do contain the OpenID Connect nonce.  Doing so would unnecessar=
ily break things and create confusion in the marketplace.
>>=20
>> =20
>>=20
>>                                                           -- Mike
>>=20
>> =20
>>=20
>> From: OAuth  On Behalf Of Dick Hardt
>> Sent: Wednesday, May 6, 2020 10:48 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>=20
>> =20
>>=20
>> Hello!
>>=20
>> =20
>>=20
>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t practice for OAuth 2.0. It is not common in OpenID Connect servers as the n=
once solves some of the issues that PKCE protects against. We think that mos=
t OpenID Connect implementations also support OAuth 2.0, and hence have supp=
ort for PKCE if following best practices.
>>=20
>> =20
>>=20
>> The advantages or requiring PKCE are:
>>=20
>> =20
>>=20
>> - a simpler programming model across all OAuth applications and profiles a=
s they all use PKCE
>>=20
>> =20
>>=20
>> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r is sent through the browser instead of the clear text value
>>=20
>> =20
>>=20
>> - enforcement by AS not client - makes it easier to handle for client dev=
elopers and AS can ensure the check is conducted
>>=20
>> =20
>>=20
>> What are disadvantages besides the potential impact to OpenID Connect dep=
loyments? How significant is that impact?
>>=20
>> =20
>>=20
>> Dick, Aaron, and Torsten
>>=20
>> =20
>>=20
>> =E1=90=A7
>>=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-7FC3F358-FE4C-470E-BBD7-7A9DB8CE3631
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Mike,

The point of 2.1 i=
s to raise the security bar. 

Yes it adds new M=
UST requirements. 

But what about OIDC would b=
reak other than required implementation of PKCE to support 2.1?
Eg Would additional signaling be required to facilitate interop=
erability and migration between versions? Would that be an oauth issue or an=
 OIDC one?

Phil

On May 6, 2020, at 11:56 AM, Aaron Parecki=
 <aaron@parecki.com> wrote:

=EF=BB=BF
> In particular=
, authorization servers shouldn=E2=80=99t be required to support PKCE when t=
hey already support the OpenID Connect nonce.

T=
he Security BCP already requires that ASs support PKCE: h=
ttps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1=
 Are you suggesting that the Security BCP change that requirement a=
s well? If so, that's a discussion that needs to be had ASAP. If not, then t=
hat's an implicit statement that it's okay for OpenID Connect implementation=
s to not be best-practice OAuth implementations. And if that's the case, the=
n I also think it's acceptable that they are not complete OAuth 2.1 implemen=
tations either.





On Wed, May 6, 2020 at 11:21 AM Mike Jones <Michael.Jo=
nes=3D40microsoft.com@dmar=
c.ietf.org> wrote:











The disadvantage o=
f requiring PKCE for OpenID Connect implementations is that you=E2=80=99re t=
rying to add a normative requirement that=E2=80=99s not required of OpenID C=
onnect deployments today, which would bifurcate the ecosystem. 
 There are hundreds of implementations (including the 141 certified ones at <=
a href=3D"https://openid.net/certification/" target=3D"_blank">
https://openid.net/c=
ertification/), none of which have ever been required to support P=
KCE.  Therefore, most don=E2=80=99t.


 


Per feedback alrea=
dy provided, I believe that OAuth 2.1 should align with the guidance already=
 in the draft Security BCP, requiring EITHER the use of PKCE or the OpenID C=
onnect nonce.  Trying to retroactively
 impose unnecessary requirements on existing deployments is unlikely to succ=
eed and will significantly reduce the relevance of the OAuth 2.1 effort.<=
/u>


 


In particular, aut=
horization servers shouldn=E2=80=99t be required to support PKCE when they a=
lready support the OpenID Connect nonce.  And clients shouldn=E2=80=99t=
 reject responses from servers that don=E2=80=99t support PKCE when
 they do contain the OpenID Connect nonce.  Doing so would unnecessaril=
y break things and create confusion in the marketplace.=



 


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


 




From: OAuth <oauth-bounces@ietf.org> On Behalf Of=
 
Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.or=
g

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




 






Hello!




 






We would like to have PKCE be a MUST in OAuth 2.1 cod=
e flows. This is best practice for OAuth 2.0. It is not common in OpenID Con=
nect servers as the nonce solves some of the issues that PKCE protects again=
st. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence have support for PKC=
E if following best practices.






 






The advantages or requiring PKCE are:





 






- a simpler programming model across all OAuth applic=
ations and profiles as they all use PKCE






 






- reduced attack surface when using  S256 as a f=
ingerprint of the verifier is sent through the browser instead of the clear t=
ext value






 






- enforcement by AS not client - makes it easier to h=
andle for client developers and AS can ensure the check is conducted<=
u>






 






What are disadvantages besides the potential impact t=
o OpenID Connect deployments? How significant is that impact?<=
/p>





 






Dick, Aaron, and Torsten






 










=E1=90=A7








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



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

--Apple-Mail-7FC3F358-FE4C-470E-BBD7-7A9DB8CE3631--


From nobody Wed May  6 12:18:50 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B3A3A0AA8 for ; Wed,  6 May 2020 12:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE0KjQHeEsWP for ; Wed,  6 May 2020 12:18:40 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248D23A096B for ; Wed,  6 May 2020 12:18:40 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id j4so2306816otr.11 for ; Wed, 06 May 2020 12:18:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ljdSHTFJ7iZFlZPAQJ/p5WIrGNa3odbQuRhNkRO0i/0=; b=brWSelPY3PiAyYBtHX6iIKkOoQwgQgin5DkfVXhQZVD8Q01PFXi8uIYaFX+bOjQYbY pBRwbz+/topo53/ACMFBZhrq0mkSr13w42xjnA+tvlzapcDtUcAk5X048fXJUVdLZk/1 s9lv4Cc2wndIuj2LTgeh3YxJMePMfsAz1uZ9RL9tdP9qVSYPcgbFjHD0lzHGULjxywiy 0rllFrBELlioBzIjK7IHHEhtlYipVBhqr6/ySd+wK2L8dWN+WdL6ZgfB+QlAdE6DOwcQ uHaS8kZanAmvVl+dkPCBbwfRuwZKWY5EZxfSMGKuI7WpmzC7Sb3pGYSUHEy2HRLtmE9S ctGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ljdSHTFJ7iZFlZPAQJ/p5WIrGNa3odbQuRhNkRO0i/0=; b=rbjYkFnLqfctkDrtZsKQdVedmv7FQeiPv6BCHuZ5zFX1B3hBdfprBcq+hcv2rZC8BO Jh4cuCFPhgyMGZzQf6wGBT/GKnQTmmUAGD7BZRPP/X88GoYnbm9LX/lSRCOB+cEMBAGa cCretdGMbN7T8ABRX0FCjCYlhxksX5k54saDzh6Xbc/K7P6DpoT/d60cmxjrHry7ZQor EPe+s7lmuTTsw5+sU1Z9SqFoobSJCzA/Lpq6b2PK3VQX8cpc9k/EaznZLa0VfQwBEb/V BaaB2DdXKZrVnMLNwHKHr/337XdzFmpDge5pkzGbkSjecBhGZUB1hquHMj9JQhDCdpzj rvlQ==
X-Gm-Message-State: AGi0PubVsy9WWhuh4Ab3dCtkB3ieXOyPHDZFX5NwVrO1pjU4hiioFxi7 KOe5rLfKMbLiIf1wvoKOCTZelre8/ZzDRX5f0tLjn9bATiQ=
X-Google-Smtp-Source: APiQypK8sp9yxhrj8A5OgBOsufA593G+B2CHJQdsUVUn+7JG/FuFj0apJn0/pDdRPZt9ZwNV45u/Oid7LfJur42LbjM=
X-Received: by 2002:a9d:7558:: with SMTP id b24mr7715388otl.273.1588792719066;  Wed, 06 May 2020 12:18:39 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Steinar Noem 
Date: Wed, 6 May 2020 21:18:28 +0200
Message-ID: 
To: Phillip Hunt 
Cc: Aaron Parecki ,  Mike Jones ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a466b505a4ffa165"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:18:47 -0000

--000000000000a466b505a4ffa165
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

So, wouldn't a MUST just mean that we would have some OPs that are 2.1
compliant and some that aren't?

ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt =
:

> Mike,
>
> The point of 2.1 is to raise the security bar.
>
> Yes it adds new MUST requirements.
>
> But what about OIDC would break other than required implementation of PKC=
E
> to support 2.1?
>
> Eg Would additional signaling be required to facilitate interoperability
> and migration between versions? Would that be an oauth issue or an OIDC o=
ne?
>
> Phil
>
> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>
> =EF=BB=BF
> > In particular, authorization servers shouldn=E2=80=99t be required to s=
upport
> PKCE when they already support the OpenID Connect nonce.
>
> The Security BCP already requires that ASs support PKCE:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2=
.1.1 Are
> you suggesting that the Security BCP change that requirement as well? If
> so, that's a discussion that needs to be had ASAP. If not, then that's an
> implicit statement that it's okay for OpenID Connect implementations to n=
ot
> be best-practice OAuth implementations. And if that's the case, then I al=
so
> think it's acceptable that they are not complete OAuth 2.1 implementation=
s
> either.
>
>
>
>
>
>
> On Wed, May 6, 2020 at 11:21 AM Mike Jones  40microsoft.com@dmarc.ietf.org> wrote:
>
>> The disadvantage of requiring PKCE for OpenID Connect implementations is
>> that you=E2=80=99re trying to add a normative requirement that=E2=80=99s=
 not required of
>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>> There are hundreds of implementations (including the 141 certified ones =
at
>> https://openid.net/certification/), none of which have ever been
>> required to support PKCE.  Therefore, most don=E2=80=99t.
>>
>>
>>
>> Per feedback already provided, I believe that OAuth 2.1 should align wit=
h
>> the guidance already in the draft Security BCP, requiring EITHER the use=
 of
>> PKCE or the OpenID Connect nonce.  Trying to retroactively impose
>> unnecessary requirements on existing deployments is unlikely to succeed =
and
>> will significantly reduce the relevance of the OAuth 2.1 effort.
>>
>>
>>
>> In particular, authorization servers shouldn=E2=80=99t be required to su=
pport
>> PKCE when they already support the OpenID Connect nonce.  And clients
>> shouldn=E2=80=99t reject responses from servers that don=E2=80=99t suppo=
rt PKCE when they
>> do contain the OpenID Connect nonce.  Doing so would unnecessarily break
>> things and create confusion in the marketplace.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of * Dick Hardt
>> *Sent:* Wednesday, May 6, 2020 10:48 AM
>> *To:* oauth@ietf.org
>> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Hello!
>>
>>
>>
>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>> best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as
>> the nonce solves some of the issues that PKCE protects against. We think
>> that most OpenID Connect implementations also support OAuth 2.0, and
>> hence have support for PKCE if following best practices.
>>
>>
>>
>> The advantages or requiring PKCE are:
>>
>>
>>
>> - a simpler programming model across all OAuth applications and profiles
>> as they all use PKCE
>>
>>
>>
>> - reduced attack surface when using  S256 as a fingerprint of the
>> verifier is sent through the browser instead of the clear text value
>>
>>
>>
>> - enforcement by AS not client - makes it easier to handle for client
>> developers and AS can ensure the check is conducted
>>
>>
>>
>> What are disadvantages besides the potential impact to OpenID Connect
>> deployments? How significant is that impact?
>>
>>
>>
>> Dick, Aaron, and Torsten
>>
>>
>>
>> =E1=90=A7
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing 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
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |

--000000000000a466b505a4ffa165
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


So, wouldn't a MUST just mean that we would have some =
OPs that are 2.1 compliant and some that aren't?

ons. 6. mai 2020 kl. 21=
:12 skrev Phillip Hunt <p=
hil.hunt@independentid.com>:
Mike,

The point of=
 2.1 is to raise the security bar.=C2=A0

Yes it ad=
ds new MUST requirements.=C2=A0

But what about OID=
C would break other than required implementation of PKCE to support 2.1?

Eg Would additional signaling be required to facilit=
ate interoperability and migration between versions? Would that be an oauth=
 issue or an OIDC one?

Phil
=


On May 6, 2020, at 11:56 AM,=
 Aaron Parecki <a=
aron@parecki.com> wrote:

=EF=BB=BF
> In particula=
r, authorization servers shouldn=E2=80=99t be required to support PKCE when=
 they already support the OpenID Connect nonce.

The Security BCP already requires that ASs support PKCE:=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-security=
-topics-15#section-2.1.1=C2=A0Are you suggesting that the Security BCP =
change that requirement as well? If so, that's a discussion that needs =
to be had ASAP. If not, then that's an implicit statement that it's=
 okay for OpenID Connect implementations to not be best-practice OAuth impl=
ementations. And if that's the case, then I also think it's accepta=
ble that they are not complete OAuth 2.1 implementations either.
=






On We=
d, May 6, 2020 at 11:21 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ie=
tf.org> wrote:











The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D Connect deployments today, which would bifurcate the ecosystem.=C2=A0
 There are hundreds of implementations (including the 141 certified ones at=
 
https://openid.net/=
certification/), none of which have ever been required to suppor=
t PKCE.=C2=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of PKCE or the OpenI=
D Connect nonce.=C2=A0 Trying to retroactively
 impose unnecessary requirements on existing deployments is unlikely to suc=
ceed and will significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t reject responses from servers that don=E2=80=99t support PKCE when
 they do contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessari=
ly break things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of 
Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues that PKCE protects ag=
ainst. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence=C2=A0have support for PK=
CE if following best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7<=
/p>







_______________________________________________

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.org

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




-- 
Vennlig hilsen=


Steinar Noem
Partner Udelt AS
Systemutvikler<=
/div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n=
o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.=
no=C2=A0|=C2=A0


--000000000000a466b505a4ffa165--


From nobody Wed May  6 12:22:44 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C1E3A0AAA for ; Wed,  6 May 2020 12:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chakhzyzTVgq for ; Wed,  6 May 2020 12:22:40 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196133A0AB9 for ; Wed,  6 May 2020 12:22:39 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id t9so1417888pjw.0 for ; Wed, 06 May 2020 12:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=AZgu3+FJLwaiUGzGV6iO5YTEsrwsFy320tikSCbhEgk=; b=pgDffPQN8KtaY7qzdw8hY6maGr2krhHVjQPqtyoPMr1VqUW3SQq9W3bYooXBWxSv4X t5BH0vhkk74HDCJ5G2fdqnYGWNdWNJDQCcPm1/ynWjHTyy84K2s99DoGh1Ibp6g5PV/k SdmBtATGMpy2qzeEjsGf1Qnp8BdIAYHbsBR5y9Qptd1a82SMr4BQFb5+qlGkec/htUdr VeCzyaa7qsezO/AgSfXX6lZco/sr6AvJrsEAQU4CweNinAQgZKfICRgNh9UbhdKb3jmK ilZQ8somhQb+u99hulNWZ2ncYhQn0obENW1CSNmBGYn+FR2W8mB7ILdIgX2G9SVT2J/H KBqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=AZgu3+FJLwaiUGzGV6iO5YTEsrwsFy320tikSCbhEgk=; b=TA57fJXKTxale1HTfpwOjqah3LzWJ/D80AnmfBXlNQ7j5XDYlVqRjlSSOM6pfoPlpk F5vGh07N1VdHgUMYLhRsNTZ5G73csNIGRIkaaN8nYnMcm5c1qTz3kTyyZPNXWOUomTxW B9EFwqbomxy/fIMuuKu5T0or7NbQ3e76I/763LkOG6dFwiOdNqtLcjBF2k0lI+SEMkEF ZQmpJxSXJlbVyAF9W5irgPCmntgz3VWSWy31ug09swStcXlxsCbGT1IN52h3XsXfgRjX mYYFMobbMH65xBWxWdZrsUNQifzdyIlbw0gcUHS14g7wZOGgB/5kXafCuKN9itg8siK8 eZRg==
X-Gm-Message-State: AGi0PubEjAGbAstTOH7rdeIdcAGjHuO36A9bjkoZCnm7ryIJ2SYcBfsd 0rTvnNI7+RFmnLo0SSzyPjnpNJMYsto=
X-Google-Smtp-Source: APiQypKee0IBO7/5Cg3de1Zfu8yq3Qf9BJx5zTWHOYU23JTB6wQ1SqM3NGgboJrOfBp+ie1HaURRPw==
X-Received: by 2002:a17:90b:1044:: with SMTP id gq4mr10630939pjb.81.1588792959391;  Wed, 06 May 2020 12:22:39 -0700 (PDT)
Received: from ?IPv6:2605:8d80:447:361e:9465:924b:46dc:1f70? ([2605:8d80:447:361e:9465:924b:46dc:1f70]) by smtp.gmail.com with ESMTPSA id x18sm2616913pfi.22.2020.05.06.12.22.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 12:22:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-EE19F616-C5F0-4192-85C6-781279E88A2C
Content-Transfer-Encoding: 7bit
From: Phillip Hunt 
Mime-Version: 1.0 (1.0)
Date: Wed, 6 May 2020 12:22:37 -0700
Message-Id: <3C440EE8-134E-4703-A230-F2F61C025EF0@independentid.com>
References: 
Cc: Aaron Parecki , Mike Jones , "oauth@ietf.org" 
In-Reply-To: 
To: Steinar Noem 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:22:43 -0000

--Apple-Mail-EE19F616-C5F0-4192-85C6-781279E88A2C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yes. Some would be 2.0 and some2.1. Not unlike TLS versioning. =20

 Maybe i should not have said that. ;-)

Phil

> On May 6, 2020, at 12:18 PM, Steinar Noem  wrote:
>=20
> =EF=BB=BF
> So, wouldn't a MUST just mean that we would have some OPs that are 2.1 com=
pliant and some that aren't?
>=20
>> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt :
>> Mike,
>>=20
>> The point of 2.1 is to raise the security bar.=20
>>=20
>> Yes it adds new MUST requirements.=20
>>=20
>> But what about OIDC would break other than required implementation of PKC=
E to support 2.1?
>>=20
>> Eg Would additional signaling be required to facilitate interoperability a=
nd migration between versions? Would that be an oauth issue or an OIDC one?
>>=20
>> Phil
>>=20
>>>> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>>>>=20
>>> =EF=BB=BF
>>> > In particular, authorization servers shouldn=E2=80=99t be required to s=
upport PKCE when they already support the OpenID Connect nonce.
>>>=20
>>> The Security BCP already requires that ASs support PKCE: https://tools.i=
etf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 Are you sugge=
sting that the Security BCP change that requirement as well? If so, that's a=
 discussion that needs to be had ASAP. If not, then that's an implicit state=
ment that it's okay for OpenID Connect implementations to not be best-practi=
ce OAuth implementations. And if that's the case, then I also think it's acc=
eptable that they are not complete OAuth 2.1 implementations either.
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Wed, May 6, 2020 at 11:21 AM Mike Jones  wrote:
>>>> The disadvantage of requiring PKCE for OpenID Connect implementations i=
s that you=E2=80=99re trying to add a normative requirement that=E2=80=99s n=
ot required of OpenID Connect deployments today, which would bifurcate the e=
cosystem.  There are hundreds of implementations (including the 141 certifie=
d ones at https://openid.net/certification/), none of which have ever been r=
equired to support PKCE.  Therefore, most don=E2=80=99t.
>>>>=20
>>>> =20
>>>>=20
>>>> Per feedback already provided, I believe that OAuth 2.1 should align wi=
th the guidance already in the draft Security BCP, requiring EITHER the use o=
f PKCE or the OpenID Connect nonce.  Trying to retroactively impose unnecess=
ary requirements on existing deployments is unlikely to succeed and will sig=
nificantly reduce the relevance of the OAuth 2.1 effort.
>>>>=20
>>>> =20
>>>>=20
>>>> In particular, authorization servers shouldn=E2=80=99t be required to s=
upport PKCE when they already support the OpenID Connect nonce.  And clients=
 shouldn=E2=80=99t reject responses from servers that don=E2=80=99t support P=
KCE when they do contain the OpenID Connect nonce.  Doing so would unnecessa=
rily break things and create confusion in the marketplace.
>>>>=20
>>>> =20
>>>>=20
>>>>                                                           -- Mike
>>>>=20
>>>> =20
>>>>=20
>>>> From: OAuth  On Behalf Of Dick Hardt
>>>> Sent: Wednesday, May 6, 2020 10:48 AM
>>>> To: oauth@ietf.org
>>>> Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>=20
>>>> =20
>>>>=20
>>>> Hello!
>>>>=20
>>>> =20
>>>>=20
>>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is b=
est practice for OAuth 2.0. It is not common in OpenID Connect servers as th=
e nonce solves some of the issues that PKCE protects against. We think that m=
ost OpenID Connect implementations also support OAuth 2.0, and hence have su=
pport for PKCE if following best practices.
>>>>=20
>>>> =20
>>>>=20
>>>> The advantages or requiring PKCE are:
>>>>=20
>>>> =20
>>>>=20
>>>> - a simpler programming model across all OAuth applications and profile=
s as they all use PKCE
>>>>=20
>>>> =20
>>>>=20
>>>> - reduced attack surface when using  S256 as a fingerprint of the verif=
ier is sent through the browser instead of the clear text value
>>>>=20
>>>> =20
>>>>=20
>>>> - enforcement by AS not client - makes it easier to handle for client d=
evelopers and AS can ensure the check is conducted
>>>>=20
>>>> =20
>>>>=20
>>>> What are disadvantages besides the potential impact to OpenID Connect d=
eployments? How significant is that impact?
>>>>=20
>>>> =20
>>>>=20
>>>> Dick, Aaron, and Torsten
>>>>=20
>>>> =20
>>>>=20
>>>> =E1=90=A7
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> --=20
> Vennlig hilsen
>=20
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
> =20
> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |=20

--Apple-Mail-EE19F616-C5F0-4192-85C6-781279E88A2C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yes. Some would be 2.0 and some2.1. Not unl=
ike TLS versioning.  

 Maybe i should not have s=
aid that. ;-)

Phil

=

On May 6, 2020, at 12:18 PM, Steinar Noem <stei=
nar@udelt.no> wrote:

=

=EF=BB=BF
So, wouldn't a MUST just mean tha=
t we would have some OPs that are 2.1 compliant and some that aren't?
<=
br>
ons. 6. m=
ai 2020 kl. 21:12 skrev Phillip Hunt <phil.hunt@independentid.com>:
Mike,

The p=
oint of 2.1 is to raise the security bar. 

Yes=
 it adds new MUST requirements. 

But what abou=
t OIDC would break other than required implementation of PKCE to support 2.1=
?

Eg Would additional signaling be required to faci=
litate interoperability and migration between versions? Would that be an oau=
th issue or an OIDC one?

Phil

On May 6, 2020, at 11:56 AM,=
 Aaron Parecki <aa=
ron@parecki.com> wrote:

=EF=BB=BF
> In particular, a=
uthorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.

The S=
ecurity BCP already requires that ASs support PKCE: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15=
#section-2.1.1 Are you suggesting that the Security BCP change that=
 requirement as well? If so, that's a discussion that needs to be had ASAP. I=
f not, then that's an implicit statement that it's okay for OpenID Connect i=
mplementations to not be best-practice OAuth implementations. And if that's t=
he case, then I also think it's acceptable that they are not complete OAuth 2=
.1 implementations either.



=



On Wed, May 6, 2020 at 11:21 AM Mike Jones <=
;Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:











The disadvantage o=
f requiring PKCE for OpenID Connect implementations is that you=E2=80=99re t=
rying to add a normative requirement that=E2=80=99s not required of OpenID C=
onnect deployments today, which would bifurcate the ecosystem. 
 There are hundreds of implementations (including the 141 certified ones at <=
a href=3D"https://openid.net/certification/" target=3D"_blank">
https://openid.net/c=
ertification/), none of which have ever been required to support P=
KCE.  Therefore, most don=E2=80=99t.


 


Per feedback alrea=
dy provided, I believe that OAuth 2.1 should align with the guidance already=
 in the draft Security BCP, requiring EITHER the use of PKCE or the OpenID C=
onnect nonce.  Trying to retroactively
 impose unnecessary requirements on existing deployments is unlikely to succ=
eed and will significantly reduce the relevance of the OAuth 2.1 effort.<=
/u>


 


In particular, aut=
horization servers shouldn=E2=80=99t be required to support PKCE when they a=
lready support the OpenID Connect nonce.  And clients shouldn=E2=80=99t=
 reject responses from servers that don=E2=80=99t support PKCE when
 they do contain the OpenID Connect nonce.  Doing so would unnecessaril=
y break things and create confusion in the marketplace.=



 


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


 




From: OAuth <oauth-bounces@ietf.org> On Behalf Of=
 
Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.or=
g

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




 






Hello!




 






We would like to have PKCE be a MUST in OAuth 2.1 cod=
e flows. This is best practice for OAuth 2.0. It is not common in OpenID Con=
nect servers as the nonce solves some of the issues that PKCE protects again=
st. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence have support for PKC=
E if following best practices.






 






The advantages or requiring PKCE are:





 






- a simpler programming model across all OAuth applic=
ations and profiles as they all use PKCE






 






- reduced attack surface when using  S256 as a f=
ingerprint of the verifier is sent through the browser instead of the clear t=
ext value






 






- enforcement by AS not client - makes it easier to h=
andle for client developers and AS can ensure the check is conducted<=
u>






 






What are disadvantages besides the potential impact t=
o OpenID Connect deployments? How significant is that impact?<=
/p>





 






Dick, Aaron, and Torsten






 










=E1=90=A7=









_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________
OAuth m=
ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth
__________________________=
_____________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Vennlig hilsen

Steinar Noem
Partner=
 Udelt AS
Systemutvikler
 


=

--Apple-Mail-EE19F616-C5F0-4192-85C6-781279E88A2C--


From nobody Wed May  6 12:23:01 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2229F3A0B2C for ; Wed,  6 May 2020 12:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsQKz_l-8E3v for ; Wed,  6 May 2020 12:22:52 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650135.outbound.protection.outlook.com [40.107.65.135]) (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 D070E3A0AFE for ; Wed,  6 May 2020 12:22:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WNQLJRal1yDAhGL8WdrF4UzJmkZLZHCpiM4BFKtBy40BlS87O9EpuIBgjOFZUdmknM+oifI3zSgxhS8jQ4ZXpqGGysGKi6l/uiM1PTfNbbNPOzAN3tdsD9xadm3DmJOJoCXZRDsgxPHER9kfZK/nOMGkb/5/mZGEaZNjNIEE1uf3qQa8tFzk3Q3zgTNMfZrDAxJb/d7UwS5hLaOYFZizsvS+Pu3IxD65spD46vksTMjPuVulB692bmtlJitq3dpzbufIX0K2IzyYpgrGCWOl1Kq/reYwcUtSIU5UQf/YAZ7pkaJlRMTJKKzwIXoNz8dVIy0VSuZbhYEb9+R1KIqQ2Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2zzaff9+dnW0VgfG26KBggGxpQEUaNRK2L6xfJILbu8=; b=Cg9o14z5SorvintUH6J4sk6H7sn+IZjvXray35YKWK6+vVnbpbkQvvBrLBWg/KRzl8Zt2L8HmQ4JzICXchjU8o+t6rJp0619RW7M/gbumxyrJPplX309INqdkjUJP6kisKWmvXaOO/ZSAflbYyskLJZavXmITG3/BpDSVwYc8sIFoOFpEsbbAmI4Sk6d41tBQkThhkHPYR0fWzXIfj8DE0h9xh1qstKxhpqcVpi0dkq++uNmklSL8jDi44q1pG+uN56Cgl4PFhcqIMNj1pwJrSzQq6tKRfiSJDjuvGpEm2yCvrOxQmK2DTbO/pEXjeR0THU+xBXhR266qk8G8OtVIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2zzaff9+dnW0VgfG26KBggGxpQEUaNRK2L6xfJILbu8=; b=Bi0JOt/YpEokSMD961sT6QzXeI5m3Q61J8R4JnflgChfl/Yd80FDFMQHaoK7wVh05ZcMmOkyG5cS4qGQoq7rzJoE5thq1Tyde9Di5mBsQPvEXlUVP98urEREdHAw3+td+yJiV+ufpYadhNEk9plEVCp/1VBGXzL9l5xQz3/qRhw=
Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0848.namprd00.prod.outlook.com (2603:10b6:5:1bf::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3016.0; Wed, 6 May 2020 19:22:43 +0000
Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b%5]) with mapi id 15.20.3015.000; Wed, 6 May 2020 19:22:43 +0000
From: Mike Jones 
To: Aaron Parecki 
CC: Dick Hardt , "oauth@ietf.org" 
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYj0yIsbYPLqhhfTlu3+dAH+R+3ugABNVCAAADUQrA=
Date: Wed, 6 May 2020 19:22:43 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e03732e8-6315-4348-ab8c-0000b30f2687; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T19:19:38Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 60ea957b-8eef-4c26-3216-08d7f1f2d9e6
x-ms-traffictypediagnostic: DM6PR00MB0848:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: h8CksGDwTmy9bsxF2093+1BKXHF1267/XRmSRqYDgCfrUPafAh7ETWP97NwKzB6G+qX91pVDlLrlovRJPwZ8/YbR2ZOlpJRu4sqgTN6Wn6Lt2thQ4c/TwvaJ3GnMpt+LGX+7yq8BUQ70UqKGyC+E0BL4RAQWGuScWzCSIa4TuhRcAE7J9xLTaWTbC/cnpjzJhtgMGLULFmIrNNKquelJ8gG9iNIJc5pf/sLlVNemmqtH6nEijkRYO+mksIF6Ol8Ikh3WF9NowF7Al32H/fltfEHdgUi2QQsfpzY2ZTPUBMzdVg6h8ePKgQt8cuygKqQFTWpMvv3SesvDxpj3CzNbgQ1UpxjiQeYiRJlyxB2WGDtGGdg7TAunEXdvkO6w99n35kZupTO2xm4dkCwd4U8fVj0xW8kNd6ErNAHuAHHUkscby/We65bB2N4we0dPMKMh9Q7tzvPIDJPsScniDWl2v0l6BT9uTQZmMi1OUOIC2xubdrxFMcUyCEZKNPHJIzHF4k7zLMCmb8asNnUrTWWdtA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(366004)(136003)(396003)(346002)(376002)(39860400002)(33430700001)(76116006)(86362001)(66946007)(186003)(71200400001)(66446008)(33440700001)(8990500004)(66476007)(33656002)(2906002)(7696005)(966005)(166002)(64756008)(66556008)(10290500003)(52536014)(478600001)(53546011)(26005)(54906003)(6506007)(6916009)(66574014)(8676002)(9686003)(55016002)(8936002)(82960400001)(4326008)(82950400001)(5660300002)(316002)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: MI8scM7lHeyB4d+iNPCsZoi1QLl6BaI4T0m8PAAfc7J66hPPcHhSnL82R3mqVnAyOpzSdFO4amF3ZkcW06f91AjUBsedTkyqGYGa50TKD/a7CcJYt/KIUPSkI9XF+V5hP6yqcJCGAYQiUYBvk5TpU+QT5CeXg7gBwdfUGputp4MoVr8sJ9SwkrY+srmgJWAZPFFt+t7FPODjnfRx0HOSVpl3PivZ2BmVBqY8zrPBI/9VKuzWLlqQ70HasMTVthbBC1fWbnpVabeQq/GWQB08fTpzCDP350drc+Q0VJm252EfIwqxH3Vnmxa4IE3wjHRg8crTpsO3tnZRXf3yXvz/IOYhT5pzNPJUTTO6yLah2FE4yppwIGXv4aift3//StJVN3CkncCH6tCmX2pgOSjX4hp4IjvLuH3PUb+Ig2HMeIZgl83zZJU3VmrDaY6s6iCuNSAIrEnERBV1JAjDmTBR7FRrLkHdqG4KEx3NU3z97/9Wpn+CmeyqOv+3+zQGlbOixQE0qYkHsdRwHhQ2K1Mm1T+PSakJuOPV9l9JG0R+U2icuvwLE2h1hG2q4Uqo5oX0SGO/gjucu3NSy2gtwj15R2Vpp1SmAfIMQ0sHV/s+WhqS5RVef4i80F8qZOw8zBbsFrYfTUsMmEq+z+h/kzUXMD2/Vanbf3j6NSVknRfSCh3/is2lRtaxTxAZq32k4x/GRFzU5a4owhONq6ZTST5GxqgS+6GoZ/8aR0lO8yLJ9h8osOzajvNZw2h7/uNZAaYCKPkw3sjGJw3kue1SzOnpyb8Ih7uv1nYRoE25+BGPdqg=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0684C42A727B6D4E8FD2FB47F5A40DM6PR00MB0684namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 60ea957b-8eef-4c26-3216-08d7f1f2d9e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 19:22:43.5440 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: saIwzWB7TTzDm2hD/xK75E+b5rk345sq23J+2qh1s+KGhLm3KIPgcTsO0l8cyK5tTKanXmsn8jGifAdJWrmbHQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0848
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re:  OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:23:00 -0000

--_000_DM6PR00MB0684C42A727B6D4E8FD2FB47F5A40DM6PR00MB0684namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWFyb24sIHRoZSBzZWN0aW9uIHlvdSBjaXRlZCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMSBtYWtl
cyBpdCBjbGVhciB0aGF0IGNsaWVudHMgY2FuIHN1cHBvcnQgRUlUSEVSIFBLQ0Ugb3IgdGhlIE9w
ZW5JRCBDb25uZWN0IG5vbmNlLiAgIFRoZSB0ZXh0IGlzOg0KDQogICBDbGllbnRzIE1VU1QgcHJl
dmVudCBpbmplY3Rpb24gKHJlcGxheSkgb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBpbnRvDQogICB0
aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBieSBhdHRhY2tlcnMuICBUaGUgdXNlIG9mIFBLQ0Ug
W1JGQzc2MzY8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2MzY+XQ0KICAgaXMgUkVD
T01NRU5ERUQgdG8gdGhpcyBlbmQuICBUaGUgT3BlbklEIENvbm5lY3QgIm5vbmNlIiBwYXJhbWV0
ZXIgYW5kDQogICBJRCBUb2tlbiBDbGFpbSBbT3BlbklEPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNSNyZWYtT3BlbklEPl0gTUFZ
IGJlIHVzZWQgYXMgd2VsbC4gIFRoZSBQS0NFIGNoYWxsZW5nZSBvcg0KICAgT3BlbklEIENvbm5l
Y3QgIm5vbmNlIiBNVVNUIGJlIHRyYW5zYWN0aW9uLXNwZWNpZmljIGFuZCBzZWN1cmVseQ0KICAg
Ym91bmQgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVzZXIgYWdlbnQgaW4gd2hpY2ggdGhlIHRyYW5z
YWN0aW9uIHdhcw0KICAgc3RhcnRlZC4NCg0KV2Ugc2hvdWxkIG5vdCBhdHRlbXB0IHRvIGNoYW5n
ZSB0aGF0IGluIE9BdXRoIDIuMSwgYXMgZG9pbmcgc28gd291bGQgbmVlZGxlc3NseSBicmVhayBh
bHJlYWR5IHdvcmtpbmcgYW5kIHNlY3VyZSBjbGllbnRzLg0KDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBBYXJv
biBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDYsIDIw
MjAgMTE6NTYgQU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+
DQpDYzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+OyBvYXV0aEBpZXRmLm9yZw0K
U3ViamVjdDogW0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBL
Q0U/DQoNCj4gSW4gcGFydGljdWxhciwgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZG7igJl0
IGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgYWxyZWFkeSBzdXBwb3J0IHRo
ZSBPcGVuSUQgQ29ubmVjdCBub25jZS4NCg0KVGhlIFNlY3VyaXR5IEJDUCBhbHJlYWR5IHJlcXVp
cmVzIHRoYXQgQVNzIHN1cHBvcnQgUEtDRTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24tMi4xLjEgQXJlIHlvdSBz
dWdnZXN0aW5nIHRoYXQgdGhlIFNlY3VyaXR5IEJDUCBjaGFuZ2UgdGhhdCByZXF1aXJlbWVudCBh
cyB3ZWxsPyBJZiBzbywgdGhhdCdzIGEgZGlzY3Vzc2lvbiB0aGF0IG5lZWRzIHRvIGJlIGhhZCBB
U0FQLiBJZiBub3QsIHRoZW4gdGhhdCdzIGFuIGltcGxpY2l0IHN0YXRlbWVudCB0aGF0IGl0J3Mg
b2theSBmb3IgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIHRvIG5vdCBiZSBiZXN0LXBy
YWN0aWNlIE9BdXRoIGltcGxlbWVudGF0aW9ucy4gQW5kIGlmIHRoYXQncyB0aGUgY2FzZSwgdGhl
biBJIGFsc28gdGhpbmsgaXQncyBhY2NlcHRhYmxlIHRoYXQgdGhleSBhcmUgbm90IGNvbXBsZXRl
IE9BdXRoIDIuMSBpbXBsZW1lbnRhdGlvbnMgZWl0aGVyLg0KDQoNCg0KDQoNCg0KT24gV2VkLCBN
YXkgNiwgMjAyMCBhdCAxMToyMSBBTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9z
b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnPj4gd3JvdGU6DQpUaGUgZGlzYWR2YW50YWdlIG9mIHJlcXVpcmluZyBQS0NFIGZvciBPcGVu
SUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgaXMgdGhhdCB5b3XigJlyZSB0cnlpbmcgdG8gYWRk
IGEgbm9ybWF0aXZlIHJlcXVpcmVtZW50IHRoYXTigJlzIG5vdCByZXF1aXJlZCBvZiBPcGVuSUQg
Q29ubmVjdCBkZXBsb3ltZW50cyB0b2RheSwgd2hpY2ggd291bGQgYmlmdXJjYXRlIHRoZSBlY29z
eXN0ZW0uICBUaGVyZSBhcmUgaHVuZHJlZHMgb2YgaW1wbGVtZW50YXRpb25zIChpbmNsdWRpbmcg
dGhlIDE0MSBjZXJ0aWZpZWQgb25lcyBhdCBodHRwczovL29wZW5pZC5uZXQvY2VydGlmaWNhdGlv
bi8pLCBub25lIG9mIHdoaWNoIGhhdmUgZXZlciBiZWVuIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtD
RS4gIFRoZXJlZm9yZSwgbW9zdCBkb27igJl0Lg0KDQpQZXIgZmVlZGJhY2sgYWxyZWFkeSBwcm92
aWRlZCwgSSBiZWxpZXZlIHRoYXQgT0F1dGggMi4xIHNob3VsZCBhbGlnbiB3aXRoIHRoZSBndWlk
YW5jZSBhbHJlYWR5IGluIHRoZSBkcmFmdCBTZWN1cml0eSBCQ1AsIHJlcXVpcmluZyBFSVRIRVIg
dGhlIHVzZSBvZiBQS0NFIG9yIHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4gIFRyeWluZyB0byBy
ZXRyb2FjdGl2ZWx5IGltcG9zZSB1bm5lY2Vzc2FyeSByZXF1aXJlbWVudHMgb24gZXhpc3Rpbmcg
ZGVwbG95bWVudHMgaXMgdW5saWtlbHkgdG8gc3VjY2VlZCBhbmQgd2lsbCBzaWduaWZpY2FudGx5
IHJlZHVjZSB0aGUgcmVsZXZhbmNlIG9mIHRoZSBPQXV0aCAyLjEgZWZmb3J0Lg0KDQpJbiBwYXJ0
aWN1bGFyLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkbuKAmXQgYmUgcmVxdWlyZWQgdG8g
c3VwcG9ydCBQS0NFIHdoZW4gdGhleSBhbHJlYWR5IHN1cHBvcnQgdGhlIE9wZW5JRCBDb25uZWN0
IG5vbmNlLiAgQW5kIGNsaWVudHMgc2hvdWxkbuKAmXQgcmVqZWN0IHJlc3BvbnNlcyBmcm9tIHNl
cnZlcnMgdGhhdCBkb27igJl0IHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgZG8gY29udGFpbiB0aGUg
T3BlbklEIENvbm5lY3Qgbm9uY2UuICBEb2luZyBzbyB3b3VsZCB1bm5lY2Vzc2FyaWx5IGJyZWFr
IHRoaW5ncyBhbmQgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUgbWFya2V0cGxhY2UuDQoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN
aWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFdlZG5lc2Rh
eSwgTWF5IDYsIDIwMjAgMTA6NDggQU0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8N
Cg0KSGVsbG8hDQoNCldlIHdvdWxkIGxpa2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0
aCAyLjEgY29kZSBmbG93cy4gVGhpcyBpcyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0
IGlzIG5vdCBjb21tb24gaW4gT3BlbklEIENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29s
dmVzIHNvbWUgb2YgdGhlIGlzc3VlcyB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhp
bmsgdGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQg
T0F1dGggMi4wLCBhbmQgaGVuY2UgaGF2ZSBzdXBwb3J0IGZvciBQS0NFIGlmIGZvbGxvd2luZyBi
ZXN0IHByYWN0aWNlcy4NCg0KVGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOg0K
DQotIGEgc2ltcGxlciBwcm9ncmFtbWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0
aW9ucyBhbmQgcHJvZmlsZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0UNCg0KLSByZWR1Y2VkIGF0dGFj
ayBzdXJmYWNlIHdoZW4gdXNpbmcgIFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZp
ZXIgaXMgc2VudCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQg
dmFsdWUNCg0KLSBlbmZvcmNlbWVudCBieSBBUyBub3QgY2xpZW50IC0gbWFrZXMgaXQgZWFzaWVy
IHRvIGhhbmRsZSBmb3IgY2xpZW50IGRldmVsb3BlcnMgYW5kIEFTIGNhbiBlbnN1cmUgdGhlIGNo
ZWNrIGlzIGNvbmR1Y3RlZA0KDQpXaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBv
dGVudGlhbCBpbXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZp
Y2FudCBpcyB0aGF0IGltcGFjdD8NCg0KRGljaywgQWFyb24sIGFuZCBUb3JzdGVuDQoNCltodHRw
czovL21haWxmb29nYWUuLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldG
cGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5
LWIyODQ3NDRiYzE3MV3hkKcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cg==

--_000_DM6PR00MB0684C42A727B6D4E8FD2FB47F5A40DM6PR00MB0684namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
QWFyb24sIHRoZSBzZWN0aW9uIHlvdSBjaXRlZCBhdCA8L3NwYW4+DQo8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTUj
c2VjdGlvbi0yLjEuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1
dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24tMi4xLjE8L2E+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPiBtYWtlcyBpdCBjbGVhciB0aGF0IGNsaWVudHMgY2FuIHN1cHBvcnQgRUlUSEVS
IFBLQ0Ugb3IgdGhlDQogT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5ic3A7Jm5ic3A7IFRoZSB0ZXh0
IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IENsaWVudHMg
TVVTVCBwcmV2ZW50IGluamVjdGlvbiAocmVwbGF5KSBvZiBhdXRob3JpemF0aW9uIGNvZGVzIGlu
dG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlIGJ5IGF0
dGFja2Vycy4mbmJzcDsgVGhlIHVzZSBvZiBQS0NFIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNzYzNiIgdGl0bGU9IiZxdW90O1Byb29mIEtleSBmb3IgQ29kZSBFeGNo
YW5nZSBieSBPQXV0aCBQdWJsaWMgQ2xpZW50cyZxdW90OyI+UkZDNzYzNjwvYT5dPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyBpcyBSRUNPTU1FTkRFRCB0byB0aGlzIGVuZC4mbmJzcDsgVGhlIE9wZW5J
RCBDb25uZWN0ICZxdW90O25vbmNlJnF1b3Q7IHBhcmFtZXRlciBhbmQ8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7IElEIFRva2VuIENsYWltIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTUjcmVmLU9wZW5JRCIgdGl0bGU9
IiZxdW90O09wZW5JRCBDb25uZWN0IENvcmUgMS4wIGluY29ycG9yYXRpbmcgZXJyYXRhIHNldCAx
JnF1b3Q7Ij5PcGVuSUQ8L2E+XQ0KIE1BWSBiZSB1c2VkIGFzIHdlbGwuJm5ic3A7IFRoZSBQS0NF
IGNoYWxsZW5nZSBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgT3BlbklEIENvbm5lY3QgJnF1b3Q7
bm9uY2UmcXVvdDsgTVVTVCBiZSB0cmFuc2FjdGlvbi1zcGVjaWZpYyBhbmQgc2VjdXJlbHk8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7IGJvdW5kIHRvIHRoZSBjbGllbnQgYW5kIHRoZSB1c2VyIGFnZW50
IGluIHdoaWNoIHRoZSB0cmFuc2FjdGlvbiB3YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN0YXJ0
ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5XZSBzaG91bGQgbm90IGF0
dGVtcHQgdG8gY2hhbmdlIHRoYXQgaW4gT0F1dGggMi4xLCBhcyBkb2luZyBzbyB3b3VsZCBuZWVk
bGVzc2x5IGJyZWFrIGFscmVhZHkgd29ya2luZyBhbmQgc2VjdXJlIGNsaWVudHMuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg
MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj5Gcm9tOjwvYj4gQWFyb24gUGFyZWNraSAmbHQ7YWFyb25AcGFyZWNraS5jb20mZ3Q7IDxicj4N
CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSA2LCAyMDIwIDExOjU2IEFNPGJyPg0KPGI+VG86
PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K
PGI+Q2M6PC9iPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs7IG9hdXRo
QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jmd0OyBJbiBwYXJ0aWN1bGFyLCBhdXRob3JpemF0aW9uIHNlcnZlcnMg
c2hvdWxkbuKAmXQgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBQS0NFIHdoZW4gdGhleSBhbHJlYWR5
IHN1cHBvcnQgdGhlIE9wZW5JRCBDb25uZWN0IG5vbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgU2VjdXJpdHkgQkNQIGFscmVhZHkg
cmVxdWlyZXMgdGhhdCBBU3Mgc3VwcG9ydCBQS0NFOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNSNzZWN0
aW9uLTIuMS4xIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1z
ZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMTwvYT4mbmJzcDtBcmUgeW91IHN1Z2dlc3Rp
bmcNCiB0aGF0IHRoZSBTZWN1cml0eSBCQ1AgY2hhbmdlIHRoYXQgcmVxdWlyZW1lbnQgYXMgd2Vs
bD8gSWYgc28sIHRoYXQncyBhIGRpc2N1c3Npb24gdGhhdCBuZWVkcyB0byBiZSBoYWQgQVNBUC4g
SWYgbm90LCB0aGVuIHRoYXQncyBhbiBpbXBsaWNpdCBzdGF0ZW1lbnQgdGhhdCBpdCdzIG9rYXkg
Zm9yIE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyB0byBub3QgYmUgYmVzdC1wcmFjdGlj
ZSBPQXV0aCBpbXBsZW1lbnRhdGlvbnMuIEFuZCBpZiB0aGF0J3MNCiB0aGUgY2FzZSwgdGhlbiBJ
IGFsc28gdGhpbmsgaXQncyBhY2NlcHRhYmxlIHRoYXQgdGhleSBhcmUgbm90IGNvbXBsZXRlIE9B
dXRoIDIuMSBpbXBsZW1lbnRhdGlvbnMgZWl0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgNiwgMjAy
MCBhdCAxMToyMSBBTSBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzPTxhIGhyZWY9Im1haWx0
bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p
ZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj5UaGUgZGlzYWR2YW50YWdlIG9mIHJlcXVpcmluZyBQS0NFIGZvciBPcGVuSUQg
Q29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgaXMgdGhhdCB5b3XigJlyZSB0cnlpbmcgdG8gYWRkIGEg
bm9ybWF0aXZlIHJlcXVpcmVtZW50IHRoYXTigJlzIG5vdCByZXF1aXJlZCBvZiBPcGVuSUQNCiBD
b25uZWN0IGRlcGxveW1lbnRzIHRvZGF5LCB3aGljaCB3b3VsZCBiaWZ1cmNhdGUgdGhlIGVjb3N5
c3RlbS4mbmJzcDsgVGhlcmUgYXJlIGh1bmRyZWRzIG9mIGltcGxlbWVudGF0aW9ucyAoaW5jbHVk
aW5nIHRoZSAxNDEgY2VydGlmaWVkIG9uZXMgYXQNCjxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5l
dC9jZXJ0aWZpY2F0aW9uLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy
MDYwO3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL29wZW5pZC5uZXQvY2VydGlmaWNhdGlv
bi88L3NwYW4+PC9hPiksIG5vbmUgb2Ygd2hpY2ggaGF2ZSBldmVyIGJlZW4gcmVxdWlyZWQgdG8g
c3VwcG9ydCBQS0NFLiZuYnNwOyBUaGVyZWZvcmUsIG1vc3QgZG9u4oCZdC48L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy
MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QZXIgZmVlZGJhY2sgYWxyZWFkeSBwcm92aWRl
ZCwgSSBiZWxpZXZlIHRoYXQgT0F1dGggMi4xIHNob3VsZCBhbGlnbiB3aXRoIHRoZSBndWlkYW5j
ZSBhbHJlYWR5IGluIHRoZSBkcmFmdCBTZWN1cml0eSBCQ1AsIHJlcXVpcmluZyBFSVRIRVIgdGhl
IHVzZSBvZg0KIFBLQ0Ugb3IgdGhlIE9wZW5JRCBDb25uZWN0IG5vbmNlLiZuYnNwOyBUcnlpbmcg
dG8gcmV0cm9hY3RpdmVseSBpbXBvc2UgdW5uZWNlc3NhcnkgcmVxdWlyZW1lbnRzIG9uIGV4aXN0
aW5nIGRlcGxveW1lbnRzIGlzIHVubGlrZWx5IHRvIHN1Y2NlZWQgYW5kIHdpbGwgc2lnbmlmaWNh
bnRseSByZWR1Y2UgdGhlIHJlbGV2YW5jZSBvZiB0aGUgT0F1dGggMi4xIGVmZm9ydC48L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JbiBwYXJ0aWN1bGFyLCBhdXRob3Jp
emF0aW9uIHNlcnZlcnMgc2hvdWxkbuKAmXQgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBQS0NFIHdo
ZW4gdGhleSBhbHJlYWR5IHN1cHBvcnQgdGhlIE9wZW5JRCBDb25uZWN0IG5vbmNlLiZuYnNwOyBB
bmQgY2xpZW50cyBzaG91bGRu4oCZdA0KIHJlamVjdCByZXNwb25zZXMgZnJvbSBzZXJ2ZXJzIHRo
YXQgZG9u4oCZdCBzdXBwb3J0IFBLQ0Ugd2hlbiB0aGV5IGRvIGNvbnRhaW4gdGhlIE9wZW5JRCBD
b25uZWN0IG5vbmNlLiZuYnNwOyBEb2luZyBzbyB3b3VsZCB1bm5lY2Vzc2FyaWx5IGJyZWFrIHRo
aW5ncyBhbmQgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUgbWFya2V0cGxhY2UuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw
MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGljayBIYXJkdDxicj4NCjxi
PlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSA2LCAyMDIwIDEwOjQ4IEFNPGJyPg0KPGI+VG86PC9i
PiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBp
ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBPQXV0aCAyLjEgLSBy
ZXF1aXJlIFBLQ0U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+SGVsbG8hPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+V2Ugd291bGQgbGlrZSB0byBoYXZlIFBLQ0UgYmUgYSBNVVNUIGluIE9BdXRoIDIuMSBj
b2RlIGZsb3dzLiBUaGlzIGlzIGJlc3QgcHJhY3RpY2UgZm9yIE9BdXRoIDIuMC4gSXQgaXMgbm90
IGNvbW1vbiBpbiBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIGFzIHRoZSBub25jZSBzb2x2ZXMgc29t
ZSBvZiB0aGUgaXNzdWVzDQogdGhhdCBQS0NFIHByb3RlY3RzIGFnYWluc3QuIFdlIHRoaW5rIHRo
YXQgbW9zdCBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBzdXBwb3J0IE9BdXRo
IDIuMCwgYW5kIGhlbmNlJm5ic3A7aGF2ZSBzdXBwb3J0IGZvciBQS0NFIGlmIGZvbGxvd2luZyBi
ZXN0IHByYWN0aWNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlRoZSBhZHZhbnRhZ2VzIG9yIHJlcXVpcmluZyBQS0NFIGFyZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0g
YSBzaW1wbGVyIHByb2dyYW1taW5nIG1vZGVsIGFjcm9zcyBhbGwgT0F1dGggYXBwbGljYXRpb25z
IGFuZCBwcm9maWxlcyBhcyB0aGV5IGFsbCB1c2UgUEtDRTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSByZWR1Y2VkIGF0dGFjayBzdXJm
YWNlIHdoZW4gdXNpbmcmbmJzcDsgUzI1NiBhcyBhIGZpbmdlcnByaW50IG9mIHRoZSB2ZXJpZmll
ciBpcyBzZW50IHRocm91Z2ggdGhlIGJyb3dzZXIgaW5zdGVhZCBvZiB0aGUgY2xlYXIgdGV4dCB2
YWx1ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+LSBlbmZvcmNlbWVudCBieSBBUyBub3QgY2xpZW50IC0gbWFrZXMgaXQgZWFzaWVyIHRv
IGhhbmRsZSBmb3IgY2xpZW50IGRldmVsb3BlcnMgYW5kIEFTIGNhbiBlbnN1cmUgdGhlIGNoZWNr
IGlzIGNvbmR1Y3RlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+V2hhdCBhcmUgZGlzYWR2YW50YWdlcyBiZXNpZGVzIHRoZSBwb3RlbnRp
YWwgaW1wYWN0IHRvIE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlmaWNhbnQg
aXMgdGhhdCBpbXBhY3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5EaWNrLCBBYXJvbiwgYW5kIFRvcnN0ZW48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29n
YWUuLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0Qm
YW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9NDUyNDM4YmEtZDQyOS00NjU2LWFjZTktYjI4
NDc0NGJjMTcxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_DM6PR00MB0684C42A727B6D4E8FD2FB47F5A40DM6PR00MB0684namp_--


From nobody Wed May  6 12:23:36 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057A53A0AC2 for ; Wed,  6 May 2020 12:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_90y-EK83Dq for ; Wed,  6 May 2020 12:23:32 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3851A3A0B57 for ; Wed,  6 May 2020 12:23:22 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id u11so3493165iow.4 for ; Wed, 06 May 2020 12:23:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U48UQRWCa+VmQCIBjEbPY3FDLG0x1mCudwF0vowqNfk=; b=wGxDvui05LTBv1VBPAm8Y5ZGSlg+T5NhlFDeARioztEa4Zgj5B8JA/XiS2tLxx/pw6 vZrxY0T8tdOASI4NTftC8zCF3xnriVCORE8g5/X4HRBfb9QprKPodQxO9YmvcY92rIRZ KatwMhVxTz/TTnSCloPZWN5MaUxe/jdeimSIXghMBYNtpmya+/cuLib/TdoTAyR/NNZ0 7rEi5gQRuSJEshK5uE7T5+nx73Js82ioIr3l6htw2CfLtFWDwqom7IK8pCro3EK1luhU xwXUjRG06WBDYOMfTSomBM1fb2VH2qzCzawetLGr0Hz16x+L1NeNqorKNe8lrnqKprWO 25Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U48UQRWCa+VmQCIBjEbPY3FDLG0x1mCudwF0vowqNfk=; b=OSKq93neiIRq8HYzcrJwAdydQC2uIJkGglalo0oGiA82DyK4zLL0hEXHHrIO20UvHs oYF3eqlwTkKXNWRkecyHoNvYobZ4ETiyiaIleNVa8MFymP0ps/joZtOnSVp2BWiRHsW+ Y0lDcgYTJgeh55bf9e+k5uQZx16DigjweNSACf1u81LheGFjPnVjtEHN4ljChlgf9Ne5 uR18FFtIuo5V7N9eT4MlrqpmafgkSira6/EcKCdgzhd1prd4yGXCEpnM8Udr2L4DbiQf 3zQodTbH87XYUjBQI2ViW+T5EQZvtfWfhgaRNqnORsGzNNcY/CDmyd0KKNjuq4FCpfTR R6lA==
X-Gm-Message-State: AGi0PuY3lQWfs/OaND0Gi6Gzto/nN8NB4cyfNwRmbdXrY+b9WFfvNAN5 qs1R/RhUx/5RkHMm4DYzdkRM96wEZjg=
X-Google-Smtp-Source: APiQypIjTTTa7jMubdXvTf9LSz4H/gXGfHgvCahtoLh4fJa0LKFAcz4qk0pr9DRCvFFzEolfNDshRg==
X-Received: by 2002:a6b:bc85:: with SMTP id m127mr9770408iof.89.1588793000815;  Wed, 06 May 2020 12:23:20 -0700 (PDT)
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id u128sm1467450ioe.23.2020.05.06.12.23.19 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 12:23:20 -0700 (PDT)
Received: by mail-io1-f45.google.com with SMTP id z2so1598054iol.11 for ; Wed, 06 May 2020 12:23:19 -0700 (PDT)
X-Received: by 2002:a02:8666:: with SMTP id e93mr10312763jai.0.1588792999590;  Wed, 06 May 2020 12:23:19 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 6 May 2020 12:23:08 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Steinar Noem 
Cc: Phillip Hunt ,  Mike Jones ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005ccc0e05a4ffb2c7"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:23:34 -0000

--0000000000005ccc0e05a4ffb2c7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, and also, many of those providers very likely already support PKCE
already. Skimming through that list of certified OPs, I recognize many
names there from providers that I know support PKCE.

On Wed, May 6, 2020 at 12:18 PM Steinar Noem  wrote:

> So, wouldn't a MUST just mean that we would have some OPs that are 2.1
> compliant and some that aren't?
>
> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt  >:
>
>> Mike,
>>
>> The point of 2.1 is to raise the security bar.
>>
>> Yes it adds new MUST requirements.
>>
>> But what about OIDC would break other than required implementation of
>> PKCE to support 2.1?
>>
>> Eg Would additional signaling be required to facilitate interoperability
>> and migration between versions? Would that be an oauth issue or an OIDC =
one?
>>
>> Phil
>>
>> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>>
>> =EF=BB=BF
>> > In particular, authorization servers shouldn=E2=80=99t be required to =
support
>> PKCE when they already support the OpenID Connect nonce.
>>
>> The Security BCP already requires that ASs support PKCE:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
2.1.1 Are
>> you suggesting that the Security BCP change that requirement as well? If
>> so, that's a discussion that needs to be had ASAP. If not, then that's a=
n
>> implicit statement that it's okay for OpenID Connect implementations to =
not
>> be best-practice OAuth implementations. And if that's the case, then I a=
lso
>> think it's acceptable that they are not complete OAuth 2.1 implementatio=
ns
>> either.
>>
>>
>>
>>
>>
>>
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote:
>>
>>> The disadvantage of requiring PKCE for OpenID Connect implementations i=
s
>>> that you=E2=80=99re trying to add a normative requirement that=E2=80=99=
s not required of
>>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>>> There are hundreds of implementations (including the 141 certified ones=
 at
>>> https://openid.net/certification/), none of which have ever been
>>> required to support PKCE.  Therefore, most don=E2=80=99t.
>>>
>>>
>>>
>>> Per feedback already provided, I believe that OAuth 2.1 should align
>>> with the guidance already in the draft Security BCP, requiring EITHER t=
he
>>> use of PKCE or the OpenID Connect nonce.  Trying to retroactively impos=
e
>>> unnecessary requirements on existing deployments is unlikely to succeed=
 and
>>> will significantly reduce the relevance of the OAuth 2.1 effort.
>>>
>>>
>>>
>>> In particular, authorization servers shouldn=E2=80=99t be required to s=
upport
>>> PKCE when they already support the OpenID Connect nonce.  And clients
>>> shouldn=E2=80=99t reject responses from servers that don=E2=80=99t supp=
ort PKCE when they
>>> do contain the OpenID Connect nonce.  Doing so would unnecessarily brea=
k
>>> things and create confusion in the marketplace.
>>>
>>>
>>>
>>>                                                           -- Mike
>>>
>>>
>>>
>>> *From:* OAuth  *On Behalf Of * Dick Hardt
>>> *Sent:* Wednesday, May 6, 2020 10:48 AM
>>> *To:* oauth@ietf.org
>>> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>
>>>
>>>
>>> Hello!
>>>
>>>
>>>
>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>>> best practice for OAuth 2.0. It is not common in OpenID Connect servers=
 as
>>> the nonce solves some of the issues that PKCE protects against. We thin=
k
>>> that most OpenID Connect implementations also support OAuth 2.0, and
>>> hence have support for PKCE if following best practices.
>>>
>>>
>>>
>>> The advantages or requiring PKCE are:
>>>
>>>
>>>
>>> - a simpler programming model across all OAuth applications and profile=
s
>>> as they all use PKCE
>>>
>>>
>>>
>>> - reduced attack surface when using  S256 as a fingerprint of the
>>> verifier is sent through the browser instead of the clear text value
>>>
>>>
>>>
>>> - enforcement by AS not client - makes it easier to handle for client
>>> developers and AS can ensure the check is conducted
>>>
>>>
>>>
>>> What are disadvantages besides the potential impact to OpenID Connect
>>> deployments? How significant is that impact?
>>>
>>>
>>>
>>> Dick, Aaron, and Torsten
>>>
>>>
>>>
>>> =E1=90=A7
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Vennlig hilsen
>
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>
> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |
>

--0000000000005ccc0e05a4ffb2c7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, and also, many of those providers very likely already=
 support PKCE already. Skimming through that list of certified OPs, I recog=
nize many names there from providers that I know support PKCE.

On Wed, May 6=
, 2020 at 12:18 PM Steinar Noem <ste=
inar@udelt.no> wrote:
So, wouldn't a MUST just mean that we wou=
ld have some OPs that are 2.1 compliant and some that aren't?

=

ons. 6. ma=
i 2020 kl. 21:12 skrev Phillip Hunt <phil.hunt@independentid.com>:
Mike,<=
div>
The point of 2.1 is to raise the security bar.=C2=A0

Yes it adds new MUST requirements.=C2=A0
But what about OIDC would break other than required implementa=
tion of PKCE to support 2.1?

Eg Would additional s=
ignaling be required to facilitate interoperability and migration between v=
ersions? Would that be an oauth issue or an OIDC one?

<=
div>
Phil

On May 6, 2020, at 11:56 AM, Aaron Parecki <aaron@parecki.com> wrote:

=EF=BB=BF
> In particular, authorization servers shouldn=E2=80=99t b=
e required to support PKCE when they already support the OpenID Connect non=
ce.

The Security BCP already requires that ASs=
 support PKCE:=C2=A0https://tools.ietf.org=
/html/draft-ietf-oauth-security-topics-15#section-2.1.1=C2=A0Are you su=
ggesting that the Security BCP change that requirement as well? If so, that=
's a discussion that needs to be had ASAP. If not, then that's an i=
mplicit statement that it's okay for OpenID Connect implementations to =
not be best-practice OAuth implementations. And if that's the case, the=
n I also think it's acceptable that they are not complete OAuth 2.1 imp=
lementations either.




<=
div>

On Wed, May 6, 2020 at 11:21 AM Mike Jones <Mi=
chael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:











The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D Connect deployments today, which would bifurcate the ecosystem.=C2=A0
 There are hundreds of implementations (including the 141 certified ones at=
 
https://openid.net/=
certification/), none of which have ever been required to suppor=
t PKCE.=C2=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of PKCE or the OpenI=
D Connect nonce.=C2=A0 Trying to retroactively
 impose unnecessary requirements on existing deployments is unlikely to suc=
ceed and will significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t reject responses from servers that don=E2=80=99t support PKCE when
 they do contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessari=
ly break things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of 
Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues that PKCE protects ag=
ainst. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence=C2=A0have support for PK=
CE if following best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=
=90=A7








_______________________________________________

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.org

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




-- 
<=
span style=3D"color:rgb(34,34,34)">Vennlig hilsen

Ste=
inar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
|=C2=A0steinar@=
udelt.no=C2=A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.no=C2=A0|=C2=A0
<=
/div>




--0000000000005ccc0e05a4ffb2c7--


From nobody Wed May  6 12:24:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46353A0AAA for ; Wed,  6 May 2020 12:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLvHS5Kpfand for ; Wed,  6 May 2020 12:24:21 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808223A0044 for ; Wed,  6 May 2020 12:24:21 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id j8so3357709iog.13 for ; Wed, 06 May 2020 12:24:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qfmhVZa7fPXs7Pu5kb9vxQjN0wWUjyrIMqouKSsRiU0=; b=o/42ERqPYsMIitIGTS8/wBhz4GkRCFGApDTbzlCy6xJnLHAgbkdWYWZMTQR7kOCVoN jZh7kQn2V5gujbZCgJYZQ1Bv/GHx2Jw2KAI+vtAwgEkCGj+ThCvkja1Uz2aMFcISm1bc CUvMs36NwRhstUH6ATw/gCheXtNpaHfjgnwjAl3HlGyuv/IE28to9Fy6yOHqdfZHXCfS ukTl08HVFzMMSz0DZeYwhPMVB2DsyXm7m8OOytfGafnPdIWQZuE8e5ip22XGsmZliFyQ T+5y2nhx66xsDePMsN51gg5Nsza+qsuMm54OxiRmENqoYjR+zvOHAB1t2b4Ijjmn/v9W d/5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qfmhVZa7fPXs7Pu5kb9vxQjN0wWUjyrIMqouKSsRiU0=; b=OnW7nFIWboAEyFE5fHnMS2h/T2c1CMAGT9ZTdDkYpX/ZIvs3EdiIWbGemzMuxzga2g AOObGnem0ZbPgWWbZ5BS1jS4UGeRerTPb2RnfA7ylPaMx0W96/WfY71Aw0XJPkqDzgVq 7YJkuE06kPjRVexLmhdJpz/n96lQ6/G7CYn7cRDrTenXNBGxiFRJcXK0155g8cBXH8es ISdTRRjGIzPOqUEWXihL54paYPd2Hpc+iDfn9FkRiL7HjuM6g8bN52+N0y040z4t5Hjt VFf4dsnWJ+2Z+q9eCeoiWIfu0VPeDjep3Be2lTDOG0rcRrrYLRxy1S0MZnHiuW9lI7TU iNAA==
X-Gm-Message-State: AGi0PubkF29ZyljIEIHbPqJQnn3afvO5T1ojmcneMFyANJ8iIUkJQNp1 6GvYUrFQI4wQPgLY5x7yabS8IeL7Qv8=
X-Google-Smtp-Source: APiQypJdMZQQc5I8ZCVPPZHNsT17w49gVX1WUIDhP/CkuhetwAWpUNw7767e6F+8NyAV3aANlSzNaA==
X-Received: by 2002:a5e:8613:: with SMTP id z19mr9669908ioj.84.1588793059880;  Wed, 06 May 2020 12:24:19 -0700 (PDT)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id t88sm1476332ild.30.2020.05.06.12.24.18 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 12:24:19 -0700 (PDT)
Received: by mail-io1-f47.google.com with SMTP id c2so3393651iow.7 for ; Wed, 06 May 2020 12:24:18 -0700 (PDT)
X-Received: by 2002:a05:6602:1303:: with SMTP id h3mr9908449iov.14.1588793058637;  Wed, 06 May 2020 12:24:18 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 6 May 2020 12:24:07 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Mike Jones 
Cc: Dick Hardt , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000e1bd3f05a4ffb516"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re:  OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:24:24 -0000

--000000000000e1bd3f05a4ffb516
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, the BCP says *clients* may use either PKCE or nonce to prevent
authorization code injection. Shortly after that quoted segment is the
below:

> Authorization servers MUST support PKCE [RFC7636].

On Wed, May 6, 2020 at 12:22 PM Mike Jones 
wrote:

> Aaron, the section you cited at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2=
.1.1
> makes it clear that clients can support EITHER PKCE or the OpenID Connect
> nonce.   The text is:
>
>
>
>    Clients MUST prevent injection (replay) of authorization codes into
>
>    the authorization response by attackers.  The use of PKCE [RFC7636
> ]
>
>    is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
>
>    ID Token Claim [OpenID
> ]
> MAY be used as well.  The PKCE challenge or
>
>    OpenID Connect "nonce" MUST be transaction-specific and securely
>
>    bound to the client and the user agent in which the transaction was
>
>    started.
>
>
>
> We should not attempt to change that in OAuth 2.1, as doing so would
> needlessly break already working and secure clients.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Wednesday, May 6, 2020 11:56 AM
> *To:* Mike Jones 
> *Cc:* Dick Hardt ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> > In particular, authorization servers shouldn=E2=80=99t be required to s=
upport
> PKCE when they already support the OpenID Connect nonce.
>
>
>
> The Security BCP already requires that ASs support PKCE:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2=
.1.1 Are
> you suggesting that the Security BCP change that requirement as well? If
> so, that's a discussion that needs to be had ASAP. If not, then that's an
> implicit statement that it's okay for OpenID Connect implementations to n=
ot
> be best-practice OAuth implementations. And if that's the case, then I al=
so
> think it's acceptable that they are not complete OAuth 2.1 implementation=
s
> either.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 11:21 AM Mike Jones  40microsoft.com@dmarc.ietf.org> wrote:
>
> The disadvantage of requiring PKCE for OpenID Connect implementations is
> that you=E2=80=99re trying to add a normative requirement that=E2=80=99s =
not required of
> OpenID Connect deployments today, which would bifurcate the ecosystem.
> There are hundreds of implementations (including the 141 certified ones a=
t
> https://openid.net/certification/), none of which have ever been required
> to support PKCE.  Therefore, most don=E2=80=99t.
>
>
>
> Per feedback already provided, I believe that OAuth 2.1 should align with
> the guidance already in the draft Security BCP, requiring EITHER the use =
of
> PKCE or the OpenID Connect nonce.  Trying to retroactively impose
> unnecessary requirements on existing deployments is unlikely to succeed a=
nd
> will significantly reduce the relevance of the OAuth 2.1 effort.
>
>
>
> In particular, authorization servers shouldn=E2=80=99t be required to sup=
port PKCE
> when they already support the OpenID Connect nonce.  And clients shouldn=
=E2=80=99t
> reject responses from servers that don=E2=80=99t support PKCE when they d=
o contain
> the OpenID Connect nonce.  Doing so would unnecessarily break things and
> create confusion in the marketplace.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Dick Hardt
> *Sent:* Wednesday, May 6, 2020 10:48 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--000000000000e1bd3f05a4ffb516
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, the BCP says *clients* may use either PKCE or nonce t=
o prevent authorization code injection. Shortly after that quoted segment i=
s the below:

>=C2=A0Authoriz=
ation servers MUST support PKCE [RFC7636].

On Wed, May 6, 2020 =
at 12:22 PM Mike Jones <M=
ichael.Jones@microsoft.com> wrote:











Aaron, the sectio=
n you cited at 
https://tools.ietf.org/html/draft-ietf-oau=
th-security-topics-15#section-2.1.1 =
makes it clear that clients can support EITHER PKCE or the
 OpenID Connect nonce.=C2=A0=C2=A0 The text is:


=C2=A0<=
/u>


=C2=A0=C2=A0 Clients MUST prevent injection (rep=
lay) of authorization codes into


=C2=A0=C2=A0 the authorization response by attac=
kers.=C2=A0 The use of PKCE [RFC7636]


=C2=A0=C2=A0 is RECOMMENDED to this end.=C2=A0 T=
he OpenID Connect "nonce" parameter and


=C2=A0=C2=A0 ID Token Claim [OpenID]
 MAY be used as well.=C2=A0 The PKCE challenge or


=C2=A0=C2=A0 OpenID Connect "nonce" MU=
ST be transaction-specific and securely


=C2=A0=C2=A0 bound to the client and the user ag=
ent in which the transaction was


=C2=A0=C2=A0 started.


=C2=A0<=
/u>


We should not att=
empt to change that in OAuth 2.1, as doing so would needlessly break alread=
y working and secure clients.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com> 

Sent: Wednesday, May 6, 2020 11:56 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Dick Hardt <dick.hardt@gmail.com>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>




=C2=A0






> In particular, authorization servers shouldn=E2=
=80=99t be required to support PKCE when they already support the OpenID Co=
nnect nonce.






=C2=A0






The Security BCP already requires that ASs support P=
KCE:=C2=A0https://tools.ietf.org/html/draf=
t-ietf-oauth-security-topics-15#section-2.1.1=C2=A0Are you suggesting
 that the Security BCP change that requirement as well? If so, that's a=
 discussion that needs to be had ASAP. If not, then that's an implicit =
statement that it's okay for OpenID Connect implementations to not be b=
est-practice OAuth implementations. And if that's
 the case, then I also think it's acceptable that they are not complete=
 OAuth 2.1 implementations either.






=C2=A0






=C2=A0




=C2=A0






=C2=A0




=C2=A0










=C2=A0






On Wed, May 6, 2020 at 11:21 AM Mike Jones <Micha=
el.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:










The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D
 Connect deployments today, which would bifurcate the ecosystem.=C2=A0 Ther=
e are hundreds of implementations (including the 141 certified ones at
https://openid.net/certificati=
on/), none of which have ever been required to support PKCE.=C2=
=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of
 PKCE or the OpenID Connect nonce.=C2=A0 Trying to retroactively impose unn=
ecessary requirements on existing deployments is unlikely to succeed and wi=
ll significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t
 reject responses from servers that don=E2=80=99t support PKCE when they do=
 contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessarily break=
 things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7








_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth













--000000000000e1bd3f05a4ffb516--


From nobody Wed May  6 12:28:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F493A0ABB for ; Wed,  6 May 2020 12:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEb4mMywqSgv for ; Wed,  6 May 2020 12:28:54 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37473A09AD for ; Wed,  6 May 2020 12:28:53 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id f3so3505841ioj.1 for ; Wed, 06 May 2020 12:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UOIM3yWLNYerTwUv5MfdvD0bRpHhXPgAKkilxABYxIo=; b=qUepCuVnRzLyreQnGEYmHMH0Rs2I9dMgB6FUQ4Q7NJlu164FKUQxJCh97n7JSuaUbJ SWuIfY6e9fTPj1RXaqgFVtm5J5emdANM45FYQH6tCiTO20yl8QsAhk7ybDI3pQsJUbvk h0mkhTMXIDgTLlnIen8b3M5mS/S8VWBl15InGVPbW3ZA5cBdGjGh9NuAHWdGvH5HVu+0 rG0F9inHOiardLUUl4WnSN9wwoT83d2xy2Xta7sb5VriaI8vEA7bxSJ4NXRAm8OXbUUu hahmjXUJznbeMq4lKJhPYRk8zFgeVI1PZKB9eQz9fhda1WQlfcg70uEs4AJUIjVzXSsn rHzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UOIM3yWLNYerTwUv5MfdvD0bRpHhXPgAKkilxABYxIo=; b=oId4ObLWM64TVJcSz0P4oCJFkGGp3BgNzXhPgGzY5UIt1bcc8qcZyBWEnZBVL+kVwt fNUpBAIA1gadN7TIE1wIeFSqnT26X2K0Huc5X1+Y2PStPwKMo6G9bL14IAPQcRJd9ivY 2F6+fvLzuoVUvIW5QuYDrwxVZPew17tQ06J4rx1vgsUJQObO8MkyIA848E9FFzJ/qIlC LShNKeG/m+c3IPe4YwmD7OgRf0jbn9hJd1+mPwwPtzXm8zTlHLHpUDlbyUMvAvaWsl71 Uc3KhLtrJu8qVp9xdQ/7BOVgFscMIWPZJYSrFjv46pCSDUwIzz/gFzUijPCY1TKFZKDH F8yw==
X-Gm-Message-State: AGi0PuZc2Y8XNs4yaI9iNj9bE/kyLv7GqhF2IvHCOuWo6c8upniIkLxQ 4h+I3BBXEo2XKrqEs/g8nGRqqKnz4As=
X-Google-Smtp-Source: APiQypJBGGsNwJG3JO4Zq5tJhQQVUgS9OAIYFwVAnoSUSn8s8NdfgKH3NcyoCqp5MZ/v37e2SgzGGg==
X-Received: by 2002:a5d:950d:: with SMTP id d13mr9934169iom.136.1588793332171;  Wed, 06 May 2020 12:28:52 -0700 (PDT)
Received: from mail-il1-f182.google.com (mail-il1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id v9sm1488575iol.28.2020.05.06.12.28.51 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 12:28:51 -0700 (PDT)
Received: by mail-il1-f182.google.com with SMTP id b18so373474ilf.2 for ; Wed, 06 May 2020 12:28:51 -0700 (PDT)
X-Received: by 2002:a92:d484:: with SMTP id p4mr10022494ilg.307.1588793330778;  Wed, 06 May 2020 12:28:50 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 6 May 2020 12:28:39 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Steinar Noem 
Cc: Phillip Hunt ,  Mike Jones ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000001a4ae205a4ffc606"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:28:57 -0000

--0000000000001a4ae205a4ffc606
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I should add that even some OpenID Connect profiles require PKCE, such as
FAPI:

https://openid.net/specs/openid-financial-api-part-1.html#authorization-ser=
ver

So the precedent for requiring PKCE already exists within some OpenID
Connect profiles.

On Wed, May 6, 2020 at 12:23 PM Aaron Parecki  wrote:

> Yes, and also, many of those providers very likely already support PKCE
> already. Skimming through that list of certified OPs, I recognize many
> names there from providers that I know support PKCE.
>
> On Wed, May 6, 2020 at 12:18 PM Steinar Noem  wrote:
>
>> So, wouldn't a MUST just mean that we would have some OPs that are 2.1
>> compliant and some that aren't?
>>
>> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt <
>> phil.hunt@independentid.com>:
>>
>>> Mike,
>>>
>>> The point of 2.1 is to raise the security bar.
>>>
>>> Yes it adds new MUST requirements.
>>>
>>> But what about OIDC would break other than required implementation of
>>> PKCE to support 2.1?
>>>
>>> Eg Would additional signaling be required to facilitate interoperabilit=
y
>>> and migration between versions? Would that be an oauth issue or an OIDC=
 one?
>>>
>>> Phil
>>>
>>> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>>>
>>> =EF=BB=BF
>>> > In particular, authorization servers shouldn=E2=80=99t be required to=
 support
>>> PKCE when they already support the OpenID Connect nonce.
>>>
>>> The Security BCP already requires that ASs support PKCE:
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section=
-2.1.1 Are
>>> you suggesting that the Security BCP change that requirement as well? I=
f
>>> so, that's a discussion that needs to be had ASAP. If not, then that's =
an
>>> implicit statement that it's okay for OpenID Connect implementations to=
 not
>>> be best-practice OAuth implementations. And if that's the case, then I =
also
>>> think it's acceptable that they are not complete OAuth 2.1 implementati=
ons
>>> either.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 6, 2020 at 11:21 AM Mike Jones >> 40microsoft.com@dmarc.ietf.org> wrote:
>>>
>>>> The disadvantage of requiring PKCE for OpenID Connect implementations
>>>> is that you=E2=80=99re trying to add a normative requirement that=E2=
=80=99s not required of
>>>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>>>> There are hundreds of implementations (including the 141 certified one=
s at
>>>> https://openid.net/certification/), none of which have ever been
>>>> required to support PKCE.  Therefore, most don=E2=80=99t.
>>>>
>>>>
>>>>
>>>> Per feedback already provided, I believe that OAuth 2.1 should align
>>>> with the guidance already in the draft Security BCP, requiring EITHER =
the
>>>> use of PKCE or the OpenID Connect nonce.  Trying to retroactively impo=
se
>>>> unnecessary requirements on existing deployments is unlikely to succee=
d and
>>>> will significantly reduce the relevance of the OAuth 2.1 effort.
>>>>
>>>>
>>>>
>>>> In particular, authorization servers shouldn=E2=80=99t be required to =
support
>>>> PKCE when they already support the OpenID Connect nonce.  And clients
>>>> shouldn=E2=80=99t reject responses from servers that don=E2=80=99t sup=
port PKCE when they
>>>> do contain the OpenID Connect nonce.  Doing so would unnecessarily bre=
ak
>>>> things and create confusion in the marketplace.
>>>>
>>>>
>>>>
>>>>                                                           -- Mike
>>>>
>>>>
>>>>
>>>> *From:* OAuth  *On Behalf Of * Dick Hardt
>>>> *Sent:* Wednesday, May 6, 2020 10:48 AM
>>>> *To:* oauth@ietf.org
>>>> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>
>>>>
>>>>
>>>> Hello!
>>>>
>>>>
>>>>
>>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>>>> best practice for OAuth 2.0. It is not common in OpenID Connect server=
s as
>>>> the nonce solves some of the issues that PKCE protects against. We thi=
nk
>>>> that most OpenID Connect implementations also support OAuth 2.0, and
>>>> hence have support for PKCE if following best practices.
>>>>
>>>>
>>>>
>>>> The advantages or requiring PKCE are:
>>>>
>>>>
>>>>
>>>> - a simpler programming model across all OAuth applications and
>>>> profiles as they all use PKCE
>>>>
>>>>
>>>>
>>>> - reduced attack surface when using  S256 as a fingerprint of the
>>>> verifier is sent through the browser instead of the clear text value
>>>>
>>>>
>>>>
>>>> - enforcement by AS not client - makes it easier to handle for client
>>>> developers and AS can ensure the check is conducted
>>>>
>>>>
>>>>
>>>> What are disadvantages besides the potential impact to OpenID Connect
>>>> deployments? How significant is that impact?
>>>>
>>>>
>>>>
>>>> Dick, Aaron, and Torsten
>>>>
>>>>
>>>>
>>>> =E1=90=A7
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> --
>> Vennlig hilsen
>>
>> Steinar Noem
>> Partner Udelt AS
>> Systemutvikler
>>
>> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |
>>
>

--0000000000001a4ae205a4ffc606
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I should add that even some OpenID Connect profiles requir=
e PKCE, such as FAPI:

<=
div>
So the precedent for requiring PKCE already exists withi=
n some OpenID Connect profiles.

<=
div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 6, 2020 at 12:23 PM Aaron =
Parecki <aaron@parecki.com> =
wrote:
Yes, and also, many of those providers very likely already support=
 PKCE already. Skimming through that list of certified OPs, I recognize man=
y names there from providers that I know support PKCE.

On Wed, May 6, 2020 =
at 12:18 PM Steinar Noem <steinar@udelt.no> wrote:
So, wouldn't a MUST just mean =
that we would have some OPs that are 2.1 compliant and some that aren't=
?

ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt <phil.hunt@independentid.com>=
;:
Mike,

The point of 2.1 is to raise the security bar=
.=C2=A0

Yes it adds new MUST requirements.=C2=A0

But what about OIDC would break other than required=
 implementation of PKCE to support 2.1?

Eg Would a=
dditional signaling be required to facilitate interoperability and migratio=
n between versions? Would that be an oauth issue or an OIDC one?
=

Phil

On May 6, 2020, at 11:56 AM, Aaron Parecki <aaron@parecki.com> wrote:
=EF=BB=
=BF
> In particular, authorization servers shouldn=
=E2=80=99t be required to support PKCE when they already support the OpenID=
 Connect nonce.

The Security BCP already requi=
res that ASs support PKCE:=C2=A0https://to=
ols.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1=C2=
=A0Are you suggesting that the Security BCP change that requirement as well=
? If so, that's a discussion that needs to be had ASAP. If not, then th=
at's an implicit statement that it's okay for OpenID Connect implem=
entations to not be best-practice OAuth implementations. And if that's =
the case, then I also think it's acceptable that they are not complete =
OAuth 2.1 implementations either.






On Wed, May 6, 2020 at 11:21 AM Mike=
 Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
=












The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D Connect deployments today, which would bifurcate the ecosystem.=C2=A0
 There are hundreds of implementations (including the 141 certified ones at=
 
https://openid.net/=
certification/), none of which have ever been required to suppor=
t PKCE.=C2=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of PKCE or the OpenI=
D Connect nonce.=C2=A0 Trying to retroactively
 impose unnecessary requirements on existing deployments is unlikely to suc=
ceed and will significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t reject responses from servers that don=E2=80=99t support PKCE when
 they do contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessari=
ly break things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of 
Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues that PKCE protects ag=
ainst. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence=C2=A0have support for PK=
CE if following best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7








_______________________________________________

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.org

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




-- 
<=
span style=3D"color:rgb(34,34,34)">Vennlig hilsen

Ste=
inar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
|=C2=A0steinar@=
udelt.no=C2=A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.no=C2=A0|=C2=A0
<=
/div>






--0000000000001a4ae205a4ffc606--


From nobody Wed May  6 12:31:31 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557923A0ABE for ; Wed,  6 May 2020 12:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYN6SfnJKlqu for ; Wed,  6 May 2020 12:31:26 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640092.outbound.protection.outlook.com [40.107.64.92]) (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 9A1A23A0ABC for ; Wed,  6 May 2020 12:31:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MCRDZ4twCJN+jb/5MTa4DX6uOoseDvGnvPOO1/AbF/SqVQ85UBnDW0rg8XICLaSbDpZ9vtSHNl3hA5UHCzcDCALn27uZFGhMfP74nGKmLx7OPml9p2LLEQ+A0ehWz3bGhjBH3MaHH3gGUU2RCQSxZeG0EbE9MGnUUXnNWAYImf34KARCLtVuhNyHMs0UrBDGxWdG1QC2a/keXrGaMtX5OhiHVJrwU50sjKBqCD4DT7DiDo1jyr7aD2cD+Kt8DEeP5Qxd7TnyxjqOUmt0F4RkGDs67KGwhxUtPw9iz8MzhbxFchX5m+v1NPcMICFHZ3GOlWM7pZlNvAC9WiUHKivlgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j6d0wMpUr9gcnM3clavsqEv6S3OM4zgfNqe+UVQky8c=; b=AH92BRrvGKf2B2p9n2OXs0WNMukjCFdwrnIQAsbFvCjyKIWu3YuJ+LaYX+rNZ0No48/mupHSju5ayafSwOlv9yLdaGimpqTunx4U5aUalIRVRK3KW0hfije2VUP4zvOTEoyKX5xQJtHH7bJHKh4lZwSY4ZwsqWw0UDPjUu1MbgyFlTRk/tjvwyb1pmZLwyGeXT+bClK9vS/JrzxtqO9yBvqGyvefTyD9QhtvJJfKFHVre3ae8tLjBRkdlAEwL2PqFlX0BdT89pxo+eGPPLqMMVDDjdGTZql1EWQPIhMBszNAWUlAc3q2ABMGL6DomdsxI3gudjnk+mLkGuMcCyBHpw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j6d0wMpUr9gcnM3clavsqEv6S3OM4zgfNqe+UVQky8c=; b=DITXnyI1XjPnqfrHQsDMhCQ2P0xAT6YdA407QyVDUl6u9WAHI8Du1bgwzUwzBoKe0qFeJg3fDIpq1gZIZdjPHSL3KNM43qvrtnGxw9V1KKYJ77GORXkjMxFidRP7j7XlFkMlVQ6OZATrcBS2DFJwE8DQmFpEG+cZTSSyNhhvS+8=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0710.namprd00.prod.outlook.com (2603:10b6:610:a9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3010.0; Wed, 6 May 2020 19:31:24 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8%9]) with mapi id 15.20.3015.000; Wed, 6 May 2020 19:31:24 +0000
From: Mike Jones 
To: Aaron Parecki 
CC: Dick Hardt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYj3Ov0nQrLeyzeTj+arROiB9IA+Q==
Date: Wed, 6 May 2020 19:31:24 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d915bf1c-a237-4f4b-9baa-0000bdcdc8e0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T19:28:22Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3b805eef-9dbf-4493-106e-08d7f1f41080
x-ms-traffictypediagnostic: CH2PR00MB0710:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: q9yNuHFVZICJWQDPMwHkN/G6JVpCftbO3FX3pTQp/XVE27w4H9KBhx2b966dJYXnaezYYPwZvQMFjljSsDrvr969PAF6j+Ghv3s8gmmo85MWH3Sz91MGhpwUEjjIg3fXIC9NR21eVipQ2H0Ck4oXX6Ue8moMX8iYNeC4Y/BrXK9WNgOk6J31hTUZrsAygBDA+N7lme+THH7WC2CI73cbs1D1ON3T9nW2TH24rn32+WmHnh0+hrA63MAH4tBZdSZSRZs1y790TNh/HE69tadVoIiAnU+GRX4Krz3QRyTo2YW7Ay7ix7sLMivU3csfhhpbS2sCig6abMnPCHCqSasUmX7QsP60I20DkYxP95A2Jr/vl/A8+8isFoxFRJ+slx9021KpLe8sRk48N1biDMkoDv0JMwbr1tTSSsvY0yrhsiUJom2OuuXVOrtEEoisu7nwU02rGHZ//wlALQmS672EnEBiKrQAtRuPzUgvsk1fInKfggBitG9K2Ueux/00I00kTgir28XtIf0QniSUZmFvzw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(376002)(136003)(396003)(33430700001)(66446008)(86362001)(76116006)(66476007)(66556008)(26005)(64756008)(66946007)(966005)(2906002)(52536014)(166002)(186003)(66574014)(53546011)(7696005)(6506007)(55016002)(8676002)(33440700001)(4326008)(8990500004)(8936002)(5660300002)(33656002)(6916009)(478600001)(71200400001)(316002)(54906003)(82960400001)(10290500003)(9686003)(82950400001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: EvgguHxOOMu0Yj1LBpKKEFLbMqebvmAo8ROEX0maSz9vPBZkFfh099jMJPDSFXdwKnQU6/HDZi5dw/QUh1BRMGKaNbUYOnWbYXaiQW5Jpsrell8pjDNBrCRU2uH8NoVt7rx0qj+EsqW14oCPTBuyWkklSNCR1W6K9Zw9ZZlpneJ706XshRq0OdDliRiSIAlAOctmvM+ShZFDnEOlVS2JevnysCuM7gcP9J581F7fYeLQapmVhi9Qa8pTbqjGS21mnZ46+ZQd/Zb0/wrB7ipOti4KaqFEKfwNXJHXqfpWSpvE2jeDvUvbzRId2PR5XYdc/pyC9yPLYB0SoCKFdblaHMsJTl0fFdN31NF6QFgCsNgq8ifENSwvV4qSatQGffi5aYncNfaRI7JKBD12+CYzfsTR3hIqGK0KL3sS4M45MC/vuBXMct5Vo103boKpf5qWdW/L1G/c+9YsT1qebNDO1ugwG688Rv9I01GxtzR20Hsr9/0rKHBceo+GWx7l33N69yvJ9EFpvlcd4MRRkdjMrBXN3hRdTp9yUllQHWGMXjnwcDZVQh81RSQz9hth4yR37+psADrT42Qnv5KWfgs2ajwo94Pv8uYLAk1lqqNNuKwnbvIl6GvoSQi5RM4Zt6yC9+Q+NQIIZs8nzKZpqhsesG7KFoTPZwLqjb2GVV56z9LqnE+vE7SeA7tAB8O/M9u2gYNucuUtXs014II82OpKghro6awEDVjKuoWsBjIL5ht5ZZtp+dk7ZJaPApGag57ff17ojZTLMfux+jO6tY3cgsUy46fg5M+UCGL1s4qUlpc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679E201D6B65F383B978E28F5A40CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b805eef-9dbf-4493-106e-08d7f1f41080
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 19:31:24.6500 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Gr3TKhTwlav92TWbErdzPGqOClTZYhkVmmQgSm+qRqweq3ifGxeLQdTtFc/8HFBdiS79dn3HyMvkN76vNH0qLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0710
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:31:30 -0000

--_000_CH2PR00MB0679E201D6B65F383B978E28F5A40CH2PR00MB0679namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSByZWFsaXplIHdoYXQgaXQgc2F5cyBhYm91dCBzZXJ2ZXJzLiAgTXkgcG9pbnQgaXMgdGhhdCBP
QXV0aCAyLjHigJlzIHJlcXVpcmVtZW50cyBvbiBjbGllbnRzIHNob3VsZCBtYXRjaCB0aG9zZSBp
biB0aGUgc2VjdXJpdHkgQkNQIGFuZCBub3QgdHJ5IHRvIGdvIGJleW9uZCB0aGVtLg0KDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr
ZQ0KDQpGcm9tOiBBYXJvbiBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT4NClNlbnQ6IFdlZG5l
c2RheSwgTWF5IDYsIDIwMjAgMTI6MjQgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+DQpDYzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+OyBv
YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWly
ZSBQS0NFPw0KDQpZZXMsIHRoZSBCQ1Agc2F5cyAqY2xpZW50cyogbWF5IHVzZSBlaXRoZXIgUEtD
RSBvciBub25jZSB0byBwcmV2ZW50IGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uIFNob3J0
bHkgYWZ0ZXIgdGhhdCBxdW90ZWQgc2VnbWVudCBpcyB0aGUgYmVsb3c6DQoNCj4gQXV0aG9yaXph
dGlvbiBzZXJ2ZXJzIE1VU1Qgc3VwcG9ydCBQS0NFIFtSRkM3NjM2XS4NCg0KT24gV2VkLCBNYXkg
NiwgMjAyMCBhdCAxMjoyMiBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KQWFyb24sIHRo
ZSBzZWN0aW9uIHlvdSBjaXRlZCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMSBtYWtlcyBpdCBjbGVh
ciB0aGF0IGNsaWVudHMgY2FuIHN1cHBvcnQgRUlUSEVSIFBLQ0Ugb3IgdGhlIE9wZW5JRCBDb25u
ZWN0IG5vbmNlLiAgIFRoZSB0ZXh0IGlzOg0KDQogICBDbGllbnRzIE1VU1QgcHJldmVudCBpbmpl
Y3Rpb24gKHJlcGxheSkgb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBpbnRvDQogICB0aGUgYXV0aG9y
aXphdGlvbiByZXNwb25zZSBieSBhdHRhY2tlcnMuICBUaGUgdXNlIG9mIFBLQ0UgW1JGQzc2MzY8
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2MzY+XQ0KICAgaXMgUkVDT01NRU5ERUQg
dG8gdGhpcyBlbmQuICBUaGUgT3BlbklEIENvbm5lY3QgIm5vbmNlIiBwYXJhbWV0ZXIgYW5kDQog
ICBJRCBUb2tlbiBDbGFpbSBbT3BlbklEPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNSNyZWYtT3BlbklEPl0gTUFZIGJlIHVzZWQg
YXMgd2VsbC4gIFRoZSBQS0NFIGNoYWxsZW5nZSBvcg0KICAgT3BlbklEIENvbm5lY3QgIm5vbmNl
IiBNVVNUIGJlIHRyYW5zYWN0aW9uLXNwZWNpZmljIGFuZCBzZWN1cmVseQ0KICAgYm91bmQgdG8g
dGhlIGNsaWVudCBhbmQgdGhlIHVzZXIgYWdlbnQgaW4gd2hpY2ggdGhlIHRyYW5zYWN0aW9uIHdh
cw0KICAgc3RhcnRlZC4NCg0KV2Ugc2hvdWxkIG5vdCBhdHRlbXB0IHRvIGNoYW5nZSB0aGF0IGlu
IE9BdXRoIDIuMSwgYXMgZG9pbmcgc28gd291bGQgbmVlZGxlc3NseSBicmVhayBhbHJlYWR5IHdv
cmtpbmcgYW5kIHNlY3VyZSBjbGllbnRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBBYXJvbiBQYXJlY2tp
IDxhYXJvbkBwYXJlY2tpLmNvbTxtYWlsdG86YWFyb25AcGFyZWNraS5jb20+Pg0KU2VudDogV2Vk
bmVzZGF5LCBNYXkgNiwgMjAyMCAxMTo1NiBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNj
OiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFp
bC5jb20+Pjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog
W0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/DQoNCj4g
SW4gcGFydGljdWxhciwgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZG7igJl0IGJlIHJlcXVp
cmVkIHRvIHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgYWxyZWFkeSBzdXBwb3J0IHRoZSBPcGVuSUQg
Q29ubmVjdCBub25jZS4NCg0KVGhlIFNlY3VyaXR5IEJDUCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQg
QVNzIHN1cHBvcnQgUEtDRTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
b2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24tMi4xLjEgQXJlIHlvdSBzdWdnZXN0aW5n
IHRoYXQgdGhlIFNlY3VyaXR5IEJDUCBjaGFuZ2UgdGhhdCByZXF1aXJlbWVudCBhcyB3ZWxsPyBJ
ZiBzbywgdGhhdCdzIGEgZGlzY3Vzc2lvbiB0aGF0IG5lZWRzIHRvIGJlIGhhZCBBU0FQLiBJZiBu
b3QsIHRoZW4gdGhhdCdzIGFuIGltcGxpY2l0IHN0YXRlbWVudCB0aGF0IGl0J3Mgb2theSBmb3Ig
T3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIHRvIG5vdCBiZSBiZXN0LXByYWN0aWNlIE9B
dXRoIGltcGxlbWVudGF0aW9ucy4gQW5kIGlmIHRoYXQncyB0aGUgY2FzZSwgdGhlbiBJIGFsc28g
dGhpbmsgaXQncyBhY2NlcHRhYmxlIHRoYXQgdGhleSBhcmUgbm90IGNvbXBsZXRlIE9BdXRoIDIu
MSBpbXBsZW1lbnRhdGlvbnMgZWl0aGVyLg0KDQoNCg0KDQoNCg0KT24gV2VkLCBNYXkgNiwgMjAy
MCBhdCAxMToyMSBBTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBk
bWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3Jv
dGU6DQpUaGUgZGlzYWR2YW50YWdlIG9mIHJlcXVpcmluZyBQS0NFIGZvciBPcGVuSUQgQ29ubmVj
dCBpbXBsZW1lbnRhdGlvbnMgaXMgdGhhdCB5b3XigJlyZSB0cnlpbmcgdG8gYWRkIGEgbm9ybWF0
aXZlIHJlcXVpcmVtZW50IHRoYXTigJlzIG5vdCByZXF1aXJlZCBvZiBPcGVuSUQgQ29ubmVjdCBk
ZXBsb3ltZW50cyB0b2RheSwgd2hpY2ggd291bGQgYmlmdXJjYXRlIHRoZSBlY29zeXN0ZW0uICBU
aGVyZSBhcmUgaHVuZHJlZHMgb2YgaW1wbGVtZW50YXRpb25zIChpbmNsdWRpbmcgdGhlIDE0MSBj
ZXJ0aWZpZWQgb25lcyBhdCBodHRwczovL29wZW5pZC5uZXQvY2VydGlmaWNhdGlvbi8pLCBub25l
IG9mIHdoaWNoIGhhdmUgZXZlciBiZWVuIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRS4gIFRoZXJl
Zm9yZSwgbW9zdCBkb27igJl0Lg0KDQpQZXIgZmVlZGJhY2sgYWxyZWFkeSBwcm92aWRlZCwgSSBi
ZWxpZXZlIHRoYXQgT0F1dGggMi4xIHNob3VsZCBhbGlnbiB3aXRoIHRoZSBndWlkYW5jZSBhbHJl
YWR5IGluIHRoZSBkcmFmdCBTZWN1cml0eSBCQ1AsIHJlcXVpcmluZyBFSVRIRVIgdGhlIHVzZSBv
ZiBQS0NFIG9yIHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4gIFRyeWluZyB0byByZXRyb2FjdGl2
ZWx5IGltcG9zZSB1bm5lY2Vzc2FyeSByZXF1aXJlbWVudHMgb24gZXhpc3RpbmcgZGVwbG95bWVu
dHMgaXMgdW5saWtlbHkgdG8gc3VjY2VlZCBhbmQgd2lsbCBzaWduaWZpY2FudGx5IHJlZHVjZSB0
aGUgcmVsZXZhbmNlIG9mIHRoZSBPQXV0aCAyLjEgZWZmb3J0Lg0KDQpJbiBwYXJ0aWN1bGFyLCBh
dXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkbuKAmXQgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBQ
S0NFIHdoZW4gdGhleSBhbHJlYWR5IHN1cHBvcnQgdGhlIE9wZW5JRCBDb25uZWN0IG5vbmNlLiAg
QW5kIGNsaWVudHMgc2hvdWxkbuKAmXQgcmVqZWN0IHJlc3BvbnNlcyBmcm9tIHNlcnZlcnMgdGhh
dCBkb27igJl0IHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgZG8gY29udGFpbiB0aGUgT3BlbklEIENv
bm5lY3Qgbm9uY2UuICBEb2luZyBzbyB3b3VsZCB1bm5lY2Vzc2FyaWx5IGJyZWFrIHRoaW5ncyBh
bmQgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUgbWFya2V0cGxhY2UuDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy
b206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGll
dGYub3JnPj4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDYs
IDIwMjAgMTA6NDggQU0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KSGVsbG8h
DQoNCldlIHdvdWxkIGxpa2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29k
ZSBmbG93cy4gVGhpcyBpcyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBj
b21tb24gaW4gT3BlbklEIENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUg
b2YgdGhlIGlzc3VlcyB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsgdGhhdCBt
b3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1dGggMi4w
LCBhbmQgaGVuY2UgaGF2ZSBzdXBwb3J0IGZvciBQS0NFIGlmIGZvbGxvd2luZyBiZXN0IHByYWN0
aWNlcy4NCg0KVGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOg0KDQotIGEgc2lt
cGxlciBwcm9ncmFtbWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0aW9ucyBhbmQg
cHJvZmlsZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0UNCg0KLSByZWR1Y2VkIGF0dGFjayBzdXJmYWNl
IHdoZW4gdXNpbmcgIFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZpZXIgaXMgc2Vu
dCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQgdmFsdWUNCg0K
LSBlbmZvcmNlbWVudCBieSBBUyBub3QgY2xpZW50IC0gbWFrZXMgaXQgZWFzaWVyIHRvIGhhbmRs
ZSBmb3IgY2xpZW50IGRldmVsb3BlcnMgYW5kIEFTIGNhbiBlbnN1cmUgdGhlIGNoZWNrIGlzIGNv
bmR1Y3RlZA0KDQpXaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVudGlhbCBp
bXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2FudCBpcyB0
aGF0IGltcGFjdD8NCg0KRGljaywgQWFyb24sIGFuZCBUb3JzdGVuDQoNCltodHRwczovL21haWxm
b29nYWUuLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAl
M0QmdHlwZT16ZXJvY29udGVudCZndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5LWIyODQ3NDRi
YzE3MV3hkKcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

--_000_CH2PR00MB0679E201D6B65F383B978E28F5A40CH2PR00MB0679namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
SSByZWFsaXplIHdoYXQgaXQgc2F5cyBhYm91dCBzZXJ2ZXJzLiZuYnNwOyBNeSBwb2ludCBpcyB0
aGF0IE9BdXRoIDIuMeKAmXMgcmVxdWlyZW1lbnRzIG9uDQo8Yj5jbGllbnRzPC9iPiBzaG91bGQg
bWF0Y2ggdGhvc2UgaW4gdGhlIHNlY3VyaXR5IEJDUCBhbmQgbm90IHRyeSB0byBnbyBiZXlvbmQg
dGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBBYXJvbiBQYXJlY2tpICZsdDthYXJvbkBwYXJlY2tp
LmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAgMTI6MjQg
UE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwu
Y29tJmd0Ozsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X
R10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5ZZXMsIHRoZSBCQ1Agc2F5cyAqY2xpZW50cyogbWF5IHVzZSBlaXRoZXIgUEtD
RSBvciBub25jZSB0byBwcmV2ZW50IGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uIFNob3J0
bHkgYWZ0ZXIgdGhhdCBxdW90ZWQgc2VnbWVudCBpcyB0aGUgYmVsb3c6PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDtBdXRob3JpemF0aW9uIHNlcnZlcnMg
TVVTVCBzdXBwb3J0IFBLQ0UgW1JGQzc2MzZdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgNiwgMjAyMCBhdCAx
MjoyMiBQTSBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QWFyb24sIHRoZSBzZWN0
aW9uIHlvdSBjaXRlZCBhdA0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNSNzZWN0aW9uLTIuMS4xIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1
dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24tMi4xLjE8L2E+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPiBtYWtlcyBpdCBjbGVhciB0aGF0IGNsaWVudHMgY2FuIHN1cHBvcnQNCiBFSVRI
RVIgUEtDRSBvciB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5ic3A7Jm5ic3A7IFRoZSB0ZXh0
IGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBDbGll
bnRzIE1VU1QgcHJldmVudCBpbmplY3Rpb24gKHJlcGxheSkgb2YgYXV0aG9yaXphdGlvbiBjb2Rl
cyBpbnRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNl
IGJ5IGF0dGFja2Vycy4mbmJzcDsgVGhlIHVzZSBvZiBQS0NFIFs8YSBocmVmPSJodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvcmZjNzYzNiIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtQ
cm9vZiBLZXkgZm9yIENvZGUgRXhjaGFuZ2UgYnkgT0F1dGggUHVibGljIENsaWVudHMmcXVvdDsi
PlJGQzc2MzY8L2E+XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpcyBSRUNPTU1FTkRFRCB0byB0
aGlzIGVuZC4mbmJzcDsgVGhlIE9wZW5JRCBDb25uZWN0ICZxdW90O25vbmNlJnF1b3Q7IHBhcmFt
ZXRlciBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSUQgVG9rZW4gQ2xhaW0gWzxhIGhyZWY9
Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRv
cGljcy0xNSNyZWYtT3BlbklEIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O09wZW5JRCBD
b25uZWN0IENvcmUgMS4wIGluY29ycG9yYXRpbmcgZXJyYXRhIHNldCAxJnF1b3Q7Ij5PcGVuSUQ8
L2E+XQ0KIE1BWSBiZSB1c2VkIGFzIHdlbGwuJm5ic3A7IFRoZSBQS0NFIGNoYWxsZW5nZSBvcjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBPcGVuSUQgQ29ubmVjdCAmcXVvdDtub25jZSZxdW90OyBN
VVNUIGJlIHRyYW5zYWN0aW9uLXNwZWNpZmljIGFuZCBzZWN1cmVseTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw
OyZuYnNwOyBib3VuZCB0byB0aGUgY2xpZW50IGFuZCB0aGUgdXNlciBhZ2VudCBpbiB3aGljaCB0
aGUgdHJhbnNhY3Rpb24gd2FzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN0YXJ0ZWQuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s
b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+V2Ugc2hvdWxkIG5vdCBhdHRlbXB0
IHRvIGNoYW5nZSB0aGF0IGluIE9BdXRoIDIuMSwgYXMgZG9pbmcgc28gd291bGQgbmVlZGxlc3Ns
eSBicmVhayBhbHJlYWR5IHdvcmtpbmcgYW5kIHNlY3VyZSBjbGllbnRzLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw
NjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48Yj5Gcm9tOjwvYj4gQWFyb24gUGFyZWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhcm9uQHBh
cmVja2kuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWFyb25AcGFyZWNraS5jb208L2E+Jmd0Ow0KPGJy
Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAgMTE6NTYgQU08YnI+DQo8Yj5U
bzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv
c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+
Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2su
aGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+
Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h
dXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBbT0FV
VEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IEluIHBhcnRpY3VsYXIsIGF1dGhvcml6YXRp
b24gc2VydmVycyBzaG91bGRu4oCZdCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IFBLQ0Ugd2hlbiB0
aGV5IGFscmVhZHkgc3VwcG9ydCB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgU2VjdXJp
dHkgQkNQIGFscmVhZHkgcmVxdWlyZXMgdGhhdCBBU3Mgc3VwcG9ydCBQS0NFOiZuYnNwOzxhIGhy
ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5
LXRvcGljcy0xNSNzZWN0aW9uLTIuMS4xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24t
Mi4xLjE8L2E+Jm5ic3A7QXJlDQogeW91IHN1Z2dlc3RpbmcgdGhhdCB0aGUgU2VjdXJpdHkgQkNQ
IGNoYW5nZSB0aGF0IHJlcXVpcmVtZW50IGFzIHdlbGw/IElmIHNvLCB0aGF0J3MgYSBkaXNjdXNz
aW9uIHRoYXQgbmVlZHMgdG8gYmUgaGFkIEFTQVAuIElmIG5vdCwgdGhlbiB0aGF0J3MgYW4gaW1w
bGljaXQgc3RhdGVtZW50IHRoYXQgaXQncyBva2F5IGZvciBPcGVuSUQgQ29ubmVjdCBpbXBsZW1l
bnRhdGlvbnMgdG8gbm90IGJlIGJlc3QtcHJhY3RpY2UgT0F1dGggaW1wbGVtZW50YXRpb25zLg0K
IEFuZCBpZiB0aGF0J3MgdGhlIGNhc2UsIHRoZW4gSSBhbHNvIHRoaW5rIGl0J3MgYWNjZXB0YWJs
ZSB0aGF0IHRoZXkgYXJlIG5vdCBjb21wbGV0ZSBPQXV0aCAyLjEgaW1wbGVtZW50YXRpb25zIGVp
dGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMToyMSBB
TSBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29m
dC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1h
cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZSBk
aXNhZHZhbnRhZ2Ugb2YgcmVxdWlyaW5nIFBLQ0UgZm9yIE9wZW5JRCBDb25uZWN0IGltcGxlbWVu
dGF0aW9ucyBpcyB0aGF0IHlvdeKAmXJlIHRyeWluZyB0byBhZGQgYSBub3JtYXRpdmUgcmVxdWly
ZW1lbnQgdGhhdOKAmXMgbm90IHJlcXVpcmVkIG9mIE9wZW5JRA0KIENvbm5lY3QgZGVwbG95bWVu
dHMgdG9kYXksIHdoaWNoIHdvdWxkIGJpZnVyY2F0ZSB0aGUgZWNvc3lzdGVtLiZuYnNwOyBUaGVy
ZSBhcmUgaHVuZHJlZHMgb2YgaW1wbGVtZW50YXRpb25zIChpbmNsdWRpbmcgdGhlIDE0MSBjZXJ0
aWZpZWQgb25lcyBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQubmV0L2NlcnRpZmljYXRpb24v
IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjA7dGV4dC1kZWNvcmF0
aW9uOm5vbmUiPmh0dHBzOi8vb3BlbmlkLm5ldC9jZXJ0aWZpY2F0aW9uLzwvc3Bhbj48L2E+KSwg
bm9uZSBvZiB3aGljaCBoYXZlIGV2ZXIgYmVlbiByZXF1aXJlZCB0byBzdXBwb3J0IFBLQ0UuJm5i
c3A7IFRoZXJlZm9yZSwgbW9zdCBkb27igJl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPlBlciBmZWVkYmFjayBhbHJlYWR5IHByb3ZpZGVkLCBJIGJlbGlldmUgdGhh
dCBPQXV0aCAyLjEgc2hvdWxkIGFsaWduIHdpdGggdGhlIGd1aWRhbmNlIGFscmVhZHkgaW4gdGhl
IGRyYWZ0IFNlY3VyaXR5IEJDUCwgcmVxdWlyaW5nIEVJVEhFUiB0aGUgdXNlIG9mDQogUEtDRSBv
ciB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5ic3A7IFRyeWluZyB0byByZXRyb2FjdGl2ZWx5
IGltcG9zZSB1bm5lY2Vzc2FyeSByZXF1aXJlbWVudHMgb24gZXhpc3RpbmcgZGVwbG95bWVudHMg
aXMgdW5saWtlbHkgdG8gc3VjY2VlZCBhbmQgd2lsbCBzaWduaWZpY2FudGx5IHJlZHVjZSB0aGUg
cmVsZXZhbmNlIG9mIHRoZSBPQXV0aCAyLjEgZWZmb3J0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPkluIHBhcnRpY3VsYXIsIGF1dGhvcml6YXRpb24gc2VydmVycyBz
aG91bGRu4oCZdCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IFBLQ0Ugd2hlbiB0aGV5IGFscmVhZHkg
c3VwcG9ydCB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5ic3A7IEFuZCBjbGllbnRzIHNob3Vs
ZG7igJl0DQogcmVqZWN0IHJlc3BvbnNlcyBmcm9tIHNlcnZlcnMgdGhhdCBkb27igJl0IHN1cHBv
cnQgUEtDRSB3aGVuIHRoZXkgZG8gY29udGFpbiB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5i
c3A7IERvaW5nIHNvIHdvdWxkIHVubmVjZXNzYXJpbHkgYnJlYWsgdGhpbmdzIGFuZCBjcmVhdGUg
Y29uZnVzaW9uIGluIHRoZSBtYXJrZXRwbGFjZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj
b2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux
RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0
Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5EaWNrIEhhcmR0PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l
c2RheSwgTWF5IDYsIDIwMjAgMTA6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0
bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4N
CjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT88bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZWxsbyE8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSB3b3VsZCBs
aWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUgZmxvd3MuIFRoaXMg
aXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29tbW9uIGluIE9wZW5J
RCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9mIHRoZSBpc3N1ZXMN
CiB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsgdGhhdCBtb3N0IE9wZW5JRCBD
b25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1dGggMi4wLCBhbmQgaGVuY2Um
bmJzcDtoYXZlIHN1cHBvcnQgZm9yIFBLQ0UgaWYgZm9sbG93aW5nIGJlc3QgcHJhY3RpY2VzLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
VGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBhIHNpbXBsZXIgcHJvZ3Jh
bW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHByb2ZpbGVzIGFz
IHRoZXkgYWxsIHVzZSBQS0NFPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4tIHJlZHVjZWQgYXR0YWNrIHN1cmZhY2Ugd2hlbiB1c2luZyZu
YnNwOyBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlmaWVyIGlzIHNlbnQgdGhyb3Vn
aCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZhbHVlPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIGVuZm9yY2Vt
ZW50IGJ5IEFTIG5vdCBjbGllbnQgLSBtYWtlcyBpdCBlYXNpZXIgdG8gaGFuZGxlIGZvciBjbGll
bnQgZGV2ZWxvcGVycyBhbmQgQVMgY2FuIGVuc3VyZSB0aGUgY2hlY2sgaXMgY29uZHVjdGVkPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5X
aGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVudGlhbCBpbXBhY3QgdG8gT3Bl
bklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2FudCBpcyB0aGF0IGltcGFjdD88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PkRpY2ssIEFhcm9uLCBhbmQgVG9yc3RlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpbWcgYm9yZGVyPSIw
IiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS4uYXBwc3BvdC5jb20v
dD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29u
dGVudCZhbXA7Z3VpZD00NTI0MzhiYS1kNDI5LTQ2NTYtYWNlOS1iMjg0NzQ0YmMxNzEiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp
ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_CH2PR00MB0679E201D6B65F383B978E28F5A40CH2PR00MB0679namp_--


From nobody Wed May  6 12:35:05 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49173A0AC2 for ; Wed,  6 May 2020 12:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQWw8O6nbYsx for ; Wed,  6 May 2020 12:35:01 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650098.outbound.protection.outlook.com [40.107.65.98]) (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 C458C3A0ABC for ; Wed,  6 May 2020 12:35:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nu9V/hEuJWGjRj6z3LixNEPy24i+ZpKM2tmyYBrO+KkPINf6q6FkdYcESYiCK7n8LbWB7z0j/usqyND9YyFV4g07qClsTe4kvJ/tG2ioacVEgSr8r/DB0HGcIxRTDLNrVPkXG89H58gygV9TJzO/wR/G8zENNmC8Cp8u3heEJjC15woJS1cmwGdaEHMC3ZF9fGrxD/ZALlMAyU4OSMt7UEF2imOFdXogGebny1CywNDVy0A6tsGRXztaPc+sSwqpXNx9BJgF+tjTZgH3kivXrNF4DY8MUFq5qAipWP3XXN+qdcBzTI+QC8BZGcjuXsL//FuqCBabXuckxG0BONjQSA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YQG7HddZ9rsn2n49w6Pltl3AoZr3xMwoctCR+QukFcQ=; b=NgOMeIxL0bO9JauEQgRFw3ZPW7S9x07Qoh2drqLEMibEUK/3mo/M8YZfIQeJUKYk5jKQpF1/fCw+qTSdJbngSOsDfUPrJ7oqjTkZHqU9+amjSgsY8gIRGp9jaUE9kdTMyTTDERZ+GZDFNzdUZf6Y1bFngMXUwbJk+VKLdLeTyvBeoyTNTBKuZzHD9uXzh8V/VJffaHjqz/sXOIhkFY4gctAraIrZT1iC0fV853QmK5HXvtQA27BG8IfF9jxcdjVouep9gFEMH8pPqD5NOOPDlNy2BOSf3V+1xkwz43QVD9SnE650lFpv2/w5dhmOGRToBdFltBfaIqYVI2z9vb0q2A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YQG7HddZ9rsn2n49w6Pltl3AoZr3xMwoctCR+QukFcQ=; b=WihbDg2SM+Ft0GaTOpayWGRzdhEWfqIr++YF5Xi7X2uVTcSiuUAbQjLMFXvFtbxKSanV4f3gI053qBaHYBU9Rc8w3c8Ra7mTO10taIiadNB5OVvwoseesi5XIaXjgLlJYxOa1pWsmFgDOa5UHbfw+g9fx+kaQmQAB4B1IOphLnI=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0796.namprd00.prod.outlook.com (2603:10b6:610:6f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3013.0; Wed, 6 May 2020 19:34:58 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8%9]) with mapi id 15.20.3015.000; Wed, 6 May 2020 19:34:58 +0000
From: Mike Jones 
To: Aaron Parecki , Steinar Noem 
CC: Phillip Hunt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYj3WtR+me7qEElQpS5TJ12DTuYaw==
Date: Wed, 6 May 2020 19:34:57 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=8cb56d76-0f41-4e22-b3a8-0000077889d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T19:31:28Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e80eda33-fbe2-4d85-162e-08d7f1f48fa4
x-ms-traffictypediagnostic: CH2PR00MB0796:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AZtrFhKpo5kNwygbHYT8KWaFBJTp4fS3M3viLCwdH0+qigW/c1uoB93VaOUWN1tYJuGCZmSYHR/J4aiDYKj34/IvOnFKMrLnEuOiZbWNEhMKaBHwLy9nHbBuYAGsKMialt/DaG90opi3U5ir8r5EoLTQ20KvJI2NnthV9pWaJR9fUvBIwDUmkq1PA2C4tCf2Lz+24/1WQMZj4x5aQFww3ENthm3pSqlywJXGSjfLpY0oxMaUaqW5Ejr8TrdU28ZqNKYF6LbU2KwJDtsi/+Sz2KDiIjQcPcP6HH0JybBfF/MN3eu2oVCNvhqdx4+OC7XTctonmbwkTxzMlAzyZx7WrXFvLIC5B8WV3MxxchoyyQp9YjJ/uxmBQRu6jEBLIzuEMiuT9ldokz0LExFXKQF3X+1fjuBlQErkLPMj8l21WhEVgEQtIGJVHrkpJFFjWOVBzS1MSU5hE9LO/xG/yr5jpE1Q/j+pgBMHI4tH2PrCgVJyYLS3FFWsCDEQ5FqIi9m+f0O8OxVUSWxPiawE64OGIQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(136003)(376002)(39860400002)(396003)(366004)(33430700001)(8936002)(8676002)(26005)(186003)(55016002)(33440700001)(4326008)(6506007)(66574014)(52536014)(7696005)(9686003)(478600001)(966005)(316002)(8990500004)(53546011)(76116006)(54906003)(10290500003)(33656002)(66446008)(82960400001)(64756008)(5660300002)(66556008)(66476007)(86362001)(82950400001)(110136005)(71200400001)(166002)(2906002)(66946007)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: BDlAVWMgFyw4BH1SMfyHujEeuuikoL/p9PW5X81yVGkPnPzGoAM5nkLwtHr9vUeo5X/XNJz1rlZp5fcffD9KjySUuoI0IgwpF+/OD6/hy/Wzv2vXO1C8VxprbYVRHnhU3yWsgCDmxfqCAGxELz4UWmaa4V6X7TBOIG/EeOWJ+NtizjLJ7udZJs0lKcqxh59yaeFv3IWHvaM1FWR3asp/i1h4yA0dYnSDTBJLziBgr6NVOGJbxHQ8iG37IpPoyvkn3/BN0UVxLEdNxPtAEUYGVzJaw+MIqCfnjcx7/8QZIN6L3oBKQyG7Q6VIGMGuPTOyl3ZczQv3h6GyrOVWGtCkILN9Gr65GIfzDQHGjxCdSXi75oqgWbyHqO31cAz75a4+vYrbdId6G/d6mJo03AEbFIxb1OUf+KQPclLWB58ZhkKGtmuzBQyD6RHIR9ZPKGxKvYk0M61FDbDELG7sfgk2cmeK8l7jYGlfZ7Wc9tByd3Fk2os2AYxS4sfCStG3tGjfiOw2WuJu7cbvbd70/PrsQVeloSydlATqjpQfLo6cFgJmtaeBmwFa4e9hwuBm5EBFKF1PCWeHEzn23gTtmdv8XE3YClsmpKH+6cw0Pk8ChMa4MspNZOaD1U+b+lS/KCrNh7yVcyYR6OM+t3xKE5af5zurMZ8vikYhuj46ifEs9R4pZPVVQnWRfyWnobk7lfQP9B2EwEaT8utFHBSF74gKU9BqFgmbz0xAYbigq+QZRG8rV/s1V1QnDCaOM4c0oNZkysg9cUFxebd79E5ynMs4QBU7uDEZUPgBb+LWJc/o+WQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB067972AFDBBCB149BD27B136F5A40CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e80eda33-fbe2-4d85-162e-08d7f1f48fa4
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 19:34:57.6640 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: o92lwYiBwd0iJw8QJj+IZWHYc9EUh0umC2liOKrmotVDU81nszKlFrTCPotA2oAhCkRJ6EPRH/LFU17sjuqNBA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0796
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 19:35:04 -0000

--_000_CH2PR00MB067972AFDBBCB149BD27B136F5A40CH2PR00MB0679namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WWVzLCBGQVBJIHJlcXVpcmVzIFBLQ0UsIHdoaWNoIGlzIGdyZWF0LiAgTWFueSBvZiBpdHMgcmVx
dWlyZW1lbnRzIGNvbWUgZnJvbSBPcGVuSUQgQ29ubmVjdCBidXQgc29tZSBvZiB0aGVtIGFyZSBp
bnRlbnRpb25hbGx5IGluY29tcGF0aWJsZSDigJMgc3VjaCBhcyByZXF1aXJpbmcgdGhhdCBCYXNp
YyBhdXRoZW50aWNhdGlvbiBub3QgYmUgc3VwcG9ydGVkLCB3aGVyZWFzIENvbm5lY3QgcmVxdWly
ZXMgdGhhdCBpdCBiZSBzdXBwb3J0ZWQuICBJdOKAmXMgYSBkaWZmZXJlbnQgZWNvc3lzdGVtIHdp
dGggZGlmZmVyZW50IHJlcXVpcmVtZW50cy4NCg0KRG9u4oCZdCBnZXQgbWUgd3JvbmcsIEkgc3Vw
cG9ydCBQS0NFIHdoZXJlIGl0IG1ha2VzIHNlbnNlLCBzdWNoIGFzIHdoZW4geW914oCZcmUgZG9p
bmcgYmFyZSBPQXV0aCB3aXRob3V0IE9wZW5JRCBDb25uZWN0LiAgQnV0IHRyeWluZyB0byBpbXBv
c2UgYW4gdW5uZWNlc3NhcnkgcmVxdWlyZW1lbnQgb24gYSB3b3JraW5nIGFuZCBzZWN1cmUgZWNv
c3lzdGVtIHdpbGwganVzdCBjcmVhdGUgZ3JpZWYgZm9yIHVzIGFuZCBvdXIgY3VzdG9tZXJzIGFu
ZCBsZXNzZW4gb3VyIGNyZWRpYmlsaXR5IGFzIHN0ZXdhcmRzIG9mIHRoZSBPQXV0aCBlY29zeXN0
ZW0uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAtLSBNaWtlDQoNCkZyb206IEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPg0K
U2VudDogV2VkbmVzZGF5LCBNYXkgNiwgMjAyMCAxMjoyOSBQTQ0KVG86IFN0ZWluYXIgTm9lbSA8
c3RlaW5hckB1ZGVsdC5ubz4NCkNjOiBQaGlsbGlwIEh1bnQgPHBoaWwuaHVudEBpbmRlcGVuZGVu
dGlkLmNvbT47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IG9hdXRo
QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBL
Q0U/DQoNCkkgc2hvdWxkIGFkZCB0aGF0IGV2ZW4gc29tZSBPcGVuSUQgQ29ubmVjdCBwcm9maWxl
cyByZXF1aXJlIFBLQ0UsIHN1Y2ggYXMgRkFQSToNCg0KaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNz
L29wZW5pZC1maW5hbmNpYWwtYXBpLXBhcnQtMS5odG1sI2F1dGhvcml6YXRpb24tc2VydmVyDQoN
ClNvIHRoZSBwcmVjZWRlbnQgZm9yIHJlcXVpcmluZyBQS0NFIGFscmVhZHkgZXhpc3RzIHdpdGhp
biBzb21lIE9wZW5JRCBDb25uZWN0IHByb2ZpbGVzLg0KDQpPbiBXZWQsIE1heSA2LCAyMDIwIGF0
IDEyOjIzIFBNIEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBw
YXJlY2tpLmNvbT4+IHdyb3RlOg0KWWVzLCBhbmQgYWxzbywgbWFueSBvZiB0aG9zZSBwcm92aWRl
cnMgdmVyeSBsaWtlbHkgYWxyZWFkeSBzdXBwb3J0IFBLQ0UgYWxyZWFkeS4gU2tpbW1pbmcgdGhy
b3VnaCB0aGF0IGxpc3Qgb2YgY2VydGlmaWVkIE9QcywgSSByZWNvZ25pemUgbWFueSBuYW1lcyB0
aGVyZSBmcm9tIHByb3ZpZGVycyB0aGF0IEkga25vdyBzdXBwb3J0IFBLQ0UuDQoNCk9uIFdlZCwg
TWF5IDYsIDIwMjAgYXQgMTI6MTggUE0gU3RlaW5hciBOb2VtIDxzdGVpbmFyQHVkZWx0Lm5vPG1h
aWx0bzpzdGVpbmFyQHVkZWx0Lm5vPj4gd3JvdGU6DQpTbywgd291bGRuJ3QgYSBNVVNUIGp1c3Qg
bWVhbiB0aGF0IHdlIHdvdWxkIGhhdmUgc29tZSBPUHMgdGhhdCBhcmUgMi4xIGNvbXBsaWFudCBh
bmQgc29tZSB0aGF0IGFyZW4ndD8NCg0Kb25zLiA2LiBtYWkgMjAyMCBrbC4gMjE6MTIgc2tyZXYg
UGhpbGxpcCBIdW50IDxwaGlsLmh1bnRAaW5kZXBlbmRlbnRpZC5jb208bWFpbHRvOnBoaWwuaHVu
dEBpbmRlcGVuZGVudGlkLmNvbT4+Og0KTWlrZSwNCg0KVGhlIHBvaW50IG9mIDIuMSBpcyB0byBy
YWlzZSB0aGUgc2VjdXJpdHkgYmFyLi4NCg0KWWVzIGl0IGFkZHMgbmV3IE1VU1QgcmVxdWlyZW1l
bnRzLg0KDQpCdXQgd2hhdCBhYm91dCBPSURDIHdvdWxkIGJyZWFrIG90aGVyIHRoYW4gcmVxdWly
ZWQgaW1wbGVtZW50YXRpb24gb2YgUEtDRSB0byBzdXBwb3J0IDIuMT8NCg0KRWcgV291bGQgYWRk
aXRpb25hbCBzaWduYWxpbmcgYmUgcmVxdWlyZWQgdG8gZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmls
aXR5IGFuZCBtaWdyYXRpb24gYmV0d2VlbiB2ZXJzaW9ucz8gV291bGQgdGhhdCBiZSBhbiBvYXV0
aCBpc3N1ZSBvciBhbiBPSURDIG9uZT8NCg0KUGhpbA0KDQoNCk9uIE1heSA2LCAyMDIwLCBhdCAx
MTo1NiBBTSwgQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb208bWFpbHRvOmFhcm9uQHBh
cmVja2kuY29tPj4gd3JvdGU6DQrvu78NCj4gSW4gcGFydGljdWxhciwgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXJzIHNob3VsZG7igJl0IGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkg
YWxyZWFkeSBzdXBwb3J0IHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4NCg0KVGhlIFNlY3VyaXR5
IEJDUCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQgQVNzIHN1cHBvcnQgUEtDRTogaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rp
b24tMi4xLjEgQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdGhlIFNlY3VyaXR5IEJDUCBjaGFuZ2Ug
dGhhdCByZXF1aXJlbWVudCBhcyB3ZWxsPyBJZiBzbywgdGhhdCdzIGEgZGlzY3Vzc2lvbiB0aGF0
IG5lZWRzIHRvIGJlIGhhZCBBU0FQLiBJZiBub3QsIHRoZW4gdGhhdCdzIGFuIGltcGxpY2l0IHN0
YXRlbWVudCB0aGF0IGl0J3Mgb2theSBmb3IgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25z
IHRvIG5vdCBiZSBiZXN0LXByYWN0aWNlIE9BdXRoIGltcGxlbWVudGF0aW9ucy4gQW5kIGlmIHRo
YXQncyB0aGUgY2FzZSwgdGhlbiBJIGFsc28gdGhpbmsgaXQncyBhY2NlcHRhYmxlIHRoYXQgdGhl
eSBhcmUgbm90IGNvbXBsZXRlIE9BdXRoIDIuMSBpbXBsZW1lbnRhdGlvbnMgZWl0aGVyLg0KDQoN
Cg0KDQoNCg0KT24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMToyMSBBTSBNaWtlIEpvbmVzIDxNaWNo
YWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3Nv
ZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpUaGUgZGlzYWR2YW50YWdlIG9mIHJlcXVp
cmluZyBQS0NFIGZvciBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgaXMgdGhhdCB5b3Xi
gJlyZSB0cnlpbmcgdG8gYWRkIGEgbm9ybWF0aXZlIHJlcXVpcmVtZW50IHRoYXTigJlzIG5vdCBy
ZXF1aXJlZCBvZiBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cyB0b2RheSwgd2hpY2ggd291bGQg
YmlmdXJjYXRlIHRoZSBlY29zeXN0ZW0uICBUaGVyZSBhcmUgaHVuZHJlZHMgb2YgaW1wbGVtZW50
YXRpb25zIChpbmNsdWRpbmcgdGhlIDE0MSBjZXJ0aWZpZWQgb25lcyBhdCBodHRwczovL29wZW5p
ZC5uZXQvY2VydGlmaWNhdGlvbi8pLCBub25lIG9mIHdoaWNoIGhhdmUgZXZlciBiZWVuIHJlcXVp
cmVkIHRvIHN1cHBvcnQgUEtDRS4gIFRoZXJlZm9yZSwgbW9zdCBkb27igJl0Lg0KDQpQZXIgZmVl
ZGJhY2sgYWxyZWFkeSBwcm92aWRlZCwgSSBiZWxpZXZlIHRoYXQgT0F1dGggMi4xIHNob3VsZCBh
bGlnbiB3aXRoIHRoZSBndWlkYW5jZSBhbHJlYWR5IGluIHRoZSBkcmFmdCBTZWN1cml0eSBCQ1As
IHJlcXVpcmluZyBFSVRIRVIgdGhlIHVzZSBvZiBQS0NFIG9yIHRoZSBPcGVuSUQgQ29ubmVjdCBu
b25jZS4gIFRyeWluZyB0byByZXRyb2FjdGl2ZWx5IGltcG9zZSB1bm5lY2Vzc2FyeSByZXF1aXJl
bWVudHMgb24gZXhpc3RpbmcgZGVwbG95bWVudHMgaXMgdW5saWtlbHkgdG8gc3VjY2VlZCBhbmQg
d2lsbCBzaWduaWZpY2FudGx5IHJlZHVjZSB0aGUgcmVsZXZhbmNlIG9mIHRoZSBPQXV0aCAyLjEg
ZWZmb3J0Lg0KDQpJbiBwYXJ0aWN1bGFyLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkbuKA
mXQgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBQS0NFIHdoZW4gdGhleSBhbHJlYWR5IHN1cHBvcnQg
dGhlIE9wZW5JRCBDb25uZWN0IG5vbmNlLiAgQW5kIGNsaWVudHMgc2hvdWxkbuKAmXQgcmVqZWN0
IHJlc3BvbnNlcyBmcm9tIHNlcnZlcnMgdGhhdCBkb27igJl0IHN1cHBvcnQgUEtDRSB3aGVuIHRo
ZXkgZG8gY29udGFpbiB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuICBEb2luZyBzbyB3b3VsZCB1
bm5lY2Vzc2FyaWx5IGJyZWFrIHRoaW5ncyBhbmQgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUgbWFy
a2V0cGxhY2UuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYu
b3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIERpY2sgSGFy
ZHQNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAgMTA6NDggQU0NClRvOiBvYXV0aEBpZXRm
Lm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIDIu
MSAtIHJlcXVpcmUgUEtDRT8NCg0KSGVsbG8hDQoNCldlIHdvdWxkIGxpa2UgdG8gaGF2ZSBQS0NF
IGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29kZSBmbG93cy4gVGhpcyBpcyBiZXN0IHByYWN0aWNl
IGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBjb21tb24gaW4gT3BlbklEIENvbm5lY3Qgc2VydmVy
cyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUgb2YgdGhlIGlzc3VlcyB0aGF0IFBLQ0UgcHJvdGVj
dHMgYWdhaW5zdC4gV2UgdGhpbmsgdGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0
aW9ucyBhbHNvIHN1cHBvcnQgT0F1dGggMi4wLCBhbmQgaGVuY2UgaGF2ZSBzdXBwb3J0IGZvciBQ
S0NFIGlmIGZvbGxvd2luZyBiZXN0IHByYWN0aWNlcy4NCg0KVGhlIGFkdmFudGFnZXMgb3IgcmVx
dWlyaW5nIFBLQ0UgYXJlOg0KDQotIGEgc2ltcGxlciBwcm9ncmFtbWluZyBtb2RlbCBhY3Jvc3Mg
YWxsIE9BdXRoIGFwcGxpY2F0aW9ucyBhbmQgcHJvZmlsZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0UN
Cg0KLSByZWR1Y2VkIGF0dGFjayBzdXJmYWNlIHdoZW4gdXNpbmcgIFMyNTYgYXMgYSBmaW5nZXJw
cmludCBvZiB0aGUgdmVyaWZpZXIgaXMgc2VudCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQg
b2YgdGhlIGNsZWFyIHRleHQgdmFsdWUNCg0KLSBlbmZvcmNlbWVudCBieSBBUyBub3QgY2xpZW50
IC0gbWFrZXMgaXQgZWFzaWVyIHRvIGhhbmRsZSBmb3IgY2xpZW50IGRldmVsb3BlcnMgYW5kIEFT
IGNhbiBlbnN1cmUgdGhlIGNoZWNrIGlzIGNvbmR1Y3RlZA0KDQpXaGF0IGFyZSBkaXNhZHZhbnRh
Z2VzIGJlc2lkZXMgdGhlIHBvdGVudGlhbCBpbXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95
bWVudHM/IEhvdyBzaWduaWZpY2FudCBpcyB0aGF0IGltcGFjdD8NCg0KRGljaywgQWFyb24sIGFu
ZCBUb3JzdGVuDQoNCltodHRwczovL21haWxmb29nYWUuLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFa
R2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTQ1MjQz
OGJhLWQ0MjktNDY1Ni1hY2U5LWIyODQ3NDRiYzE3MV3hkKcNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt
YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQotLQ0KVmVubmxpZyBo
aWxzZW4NCg0KU3RlaW5hciBOb2VtDQpQYXJ0bmVyIFVkZWx0IEFTDQpTeXN0ZW11dHZpa2xlcg0K
DQp8IHN0ZWluYXJAdWRlbHQubm88bWFpbHRvOnN0ZWluYXJAdWRlbHQubm8+IHwgaGVpQHVkZWx0
Lm5vPG1haWx0bzpoZWlAdWRlbHQubm8+ICB8ICs0NyA5NTUgMjEgNjIwIHwgd3d3LnVkZWx0Lm5v
PGh0dHA6Ly93d3cudWRlbHQubm8vPiB8DQo=

--_000_CH2PR00MB067972AFDBBCB149BD27B136F5A40CH2PR00MB0679namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
WWVzLCBGQVBJIHJlcXVpcmVzIFBLQ0UsIHdoaWNoIGlzIGdyZWF0LiZuYnNwOyBNYW55IG9mIGl0
cyByZXF1aXJlbWVudHMgY29tZSBmcm9tIE9wZW5JRCBDb25uZWN0IGJ1dCBzb21lIG9mIHRoZW0g
YXJlIGludGVudGlvbmFsbHkgaW5jb21wYXRpYmxlIOKAkyBzdWNoIGFzIHJlcXVpcmluZyB0aGF0
IEJhc2ljIGF1dGhlbnRpY2F0aW9uIG5vdCBiZSBzdXBwb3J0ZWQsIHdoZXJlYXMNCiBDb25uZWN0
IHJlcXVpcmVzIHRoYXQgaXQgYmUgc3VwcG9ydGVkLiZuYnNwOyBJdOKAmXMgYSBkaWZmZXJlbnQg
ZWNvc3lzdGVtIHdpdGggZGlmZmVyZW50IHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPkRvbuKAmXQgZ2V0IG1lIHdyb25nLCBJIHN1cHBvcnQgUEtDRSB3
aGVyZSBpdCBtYWtlcyBzZW5zZSwgc3VjaCBhcyB3aGVuIHlvdeKAmXJlIGRvaW5nIGJhcmUgT0F1
dGggd2l0aG91dCBPcGVuSUQgQ29ubmVjdC4mbmJzcDsgQnV0IHRyeWluZyB0byBpbXBvc2UgYW4g
dW5uZWNlc3NhcnkgcmVxdWlyZW1lbnQgb24gYSB3b3JraW5nIGFuZCBzZWN1cmUgZWNvc3lzdGVt
IHdpbGwganVzdA0KIGNyZWF0ZSBncmllZiBmb3IgdXMgYW5kIG91ciBjdXN0b21lcnMgYW5kIGxl
c3NlbiBvdXIgY3JlZGliaWxpdHkgYXMgc3Rld2FyZHMgb2YgdGhlIE9BdXRoIGVjb3N5c3RlbS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPkZyb206PC9iPiBBYXJvbiBQYXJlY2tpICZsdDthYXJvbkBwYXJlY2tpLmNvbSZn
dDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAgMTI6MjkgUE08YnI+
DQo8Yj5Ubzo8L2I+IFN0ZWluYXIgTm9lbSAmbHQ7c3RlaW5hckB1ZGVsdC5ubyZndDs8YnI+DQo8
Yj5DYzo8L2I+IFBoaWxsaXAgSHVudCAmbHQ7cGhpbC5odW50QGluZGVwZW5kZW50aWQuY29tJmd0
OzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozsgb2F1dGhA
aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0g
cmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNo
b3VsZCBhZGQgdGhhdCBldmVuIHNvbWUgT3BlbklEIENvbm5lY3QgcHJvZmlsZXMgcmVxdWlyZSBQ
S0NFLCBzdWNoIGFzIEZBUEk6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YSBocmVmPSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWZpbmFuY2lh
bC1hcGktcGFydC0xLmh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXIiPmh0dHBzOi8vb3BlbmlkLm5l
dC9zcGVjcy9vcGVuaWQtZmluYW5jaWFsLWFwaS1wYXJ0LTEuaHRtbCNhdXRob3JpemF0aW9uLXNl
cnZlcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+U28gdGhlIHByZWNlZGVudCBmb3IgcmVxdWlyaW5nIFBLQ0UgYWxyZWFkeSBleGlzdHMg
d2l0aGluIHNvbWUgT3BlbklEIENvbm5lY3QgcHJvZmlsZXMuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWF5IDYsIDIwMjAgYXQg
MTI6MjMgUE0gQWFyb24gUGFyZWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhcm9uQHBhcmVja2ku
Y29tIj5hYXJvbkBwYXJlY2tpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYW5kIGFs
c28sIG1hbnkgb2YgdGhvc2UgcHJvdmlkZXJzIHZlcnkgbGlrZWx5IGFscmVhZHkgc3VwcG9ydCBQ
S0NFIGFscmVhZHkuIFNraW1taW5nIHRocm91Z2ggdGhhdCBsaXN0IG9mIGNlcnRpZmllZCBPUHMs
IEkgcmVjb2duaXplIG1hbnkgbmFtZXMgdGhlcmUgZnJvbSBwcm92aWRlcnMgdGhhdCBJIGtub3cg
c3VwcG9ydCBQS0NFLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMjoxOCBQTSBTdGVpbmFyIE5vZW0gJmx0OzxhIGhy
ZWY9Im1haWx0bzpzdGVpbmFyQHVkZWx0Lm5vIiB0YXJnZXQ9Il9ibGFuayI+c3RlaW5hckB1ZGVs
dC5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB3b3VsZG4ndCBhIE1VU1QganVzdCBtZWFu
IHRoYXQgd2Ugd291bGQgaGF2ZSBzb21lIE9QcyB0aGF0IGFyZSAyLjEgY29tcGxpYW50IGFuZCBz
b21lIHRoYXQgYXJlbid0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+b25zLiA2LiBtYWkgMjAyMCBrbC4gMjE6MTIgc2tyZXYgUGhpbGxpcCBIdW50ICZsdDs8
YSBocmVmPSJtYWlsdG86cGhpbC5odW50QGluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+cGhpbC5odW50QGluZGVwZW5kZW50aWQuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbjowLi44ZXgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk1pa2UsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgcG9pbnQgb2YgMi4xIGlzIHRvIHJhaXNlIHRoZSBzZWN1cml0eSBiYXIuLiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMg
aXQgYWRkcyBuZXcgTVVTVCByZXF1aXJlbWVudHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB3aGF0IGFib3V0IE9JREMgd291
bGQgYnJlYWsgb3RoZXIgdGhhbiByZXF1aXJlZCBpbXBsZW1lbnRhdGlvbiBvZiBQS0NFIHRvIHN1
cHBvcnQgMi4xPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5FZyBXb3VsZCBhZGRpdGlvbmFsIHNpZ25hbGluZyBiZSByZXF1aXJlZCB0byBmYWNp
bGl0YXRlIGludGVyb3BlcmFiaWxpdHkgYW5kIG1pZ3JhdGlvbiBiZXR3ZWVuIHZlcnNpb25zPyBX
b3VsZCB0aGF0IGJlIGFuIG9hdXRoIGlzc3VlIG9yIGFuIE9JREMgb25lPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy
Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+T24gTWF5IDYsIDIwMjAsIGF0IDExOjU2IEFNLCBBYXJvbiBQYXJlY2tp
ICZsdDs8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20iIHRhcmdldD0iX2JsYW5rIj5h
YXJvbkBwYXJlY2tpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7vu788bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJbiBwYXJ0aWN1
bGFyLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkbuKAmXQgYmUgcmVxdWlyZWQgdG8gc3Vw
cG9ydCBQS0NFIHdoZW4gdGhleSBhbHJlYWR5IHN1cHBvcnQgdGhlIE9wZW5JRCBDb25uZWN0IG5v
bmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgU2VjdXJpdHkgQkNQIGFscmVhZHkgcmVxdWlyZXMgdGhhdCBBU3Mgc3VwcG9ydCBQS0NF
OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h
dXRoLXNlY3VyaXR5LXRvcGljcy0xNSNzZWN0aW9uLTIuMS4xIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNz
LTE1I3NlY3Rpb24tMi4xLjE8L2E+Jm5ic3A7QXJlDQogeW91IHN1Z2dlc3RpbmcgdGhhdCB0aGUg
U2VjdXJpdHkgQkNQIGNoYW5nZSB0aGF0IHJlcXVpcmVtZW50IGFzIHdlbGw/IElmIHNvLCB0aGF0
J3MgYSBkaXNjdXNzaW9uIHRoYXQgbmVlZHMgdG8gYmUgaGFkIEFTQVAuIElmIG5vdCwgdGhlbiB0
aGF0J3MgYW4gaW1wbGljaXQgc3RhdGVtZW50IHRoYXQgaXQncyBva2F5IGZvciBPcGVuSUQgQ29u
bmVjdCBpbXBsZW1lbnRhdGlvbnMgdG8gbm90IGJlIGJlc3QtcHJhY3RpY2UgT0F1dGggaW1wbGVt
ZW50YXRpb25zLg0KIEFuZCBpZiB0aGF0J3MgdGhlIGNhc2UsIHRoZW4gSSBhbHNvIHRoaW5rIGl0
J3MgYWNjZXB0YWJsZSB0aGF0IHRoZXkgYXJlIG5vdCBjb21wbGV0ZSBPQXV0aCAyLjEgaW1wbGVt
ZW50YXRpb25zIGVpdGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWF5IDYsIDIwMjAgYXQgMTE6MjEgQU0g
TWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQu
Y29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tQGRtYXJj
LmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp
biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPlRoZSBkaXNhZHZhbnRhZ2Ugb2YgcmVxdWlyaW5nIFBLQ0UgZm9yIE9wZW5J
RCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBpcyB0aGF0IHlvdeKAmXJlIHRyeWluZyB0byBhZGQg
YSBub3JtYXRpdmUgcmVxdWlyZW1lbnQgdGhhdOKAmXMgbm90IHJlcXVpcmVkIG9mIE9wZW5JRA0K
IENvbm5lY3QgZGVwbG95bWVudHMgdG9kYXksIHdoaWNoIHdvdWxkIGJpZnVyY2F0ZSB0aGUgZWNv
c3lzdGVtLiZuYnNwOyBUaGVyZSBhcmUgaHVuZHJlZHMgb2YgaW1wbGVtZW50YXRpb25zIChpbmNs
dWRpbmcgdGhlIDE0MSBjZXJ0aWZpZWQgb25lcyBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQu
bmV0L2NlcnRpZmljYXRpb24vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MDIwNjA7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vb3BlbmlkLm5ldC9jZXJ0aWZpY2F0
aW9uLzwvc3Bhbj48L2E+KSwgbm9uZSBvZiB3aGljaCBoYXZlIGV2ZXIgYmVlbiByZXF1aXJlZCB0
byBzdXBwb3J0IFBLQ0UuJm5ic3A7IFRoZXJlZm9yZSwgbW9zdCBkb27igJl0Ljwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlBlciBmZWVkYmFjayBhbHJlYWR5IHByb3Zp
ZGVkLCBJIGJlbGlldmUgdGhhdCBPQXV0aCAyLjEgc2hvdWxkIGFsaWduIHdpdGggdGhlIGd1aWRh
bmNlIGFscmVhZHkgaW4gdGhlIGRyYWZ0IFNlY3VyaXR5IEJDUCwgcmVxdWlyaW5nIEVJVEhFUiB0
aGUgdXNlIG9mDQogUEtDRSBvciB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5ic3A7IFRyeWlu
ZyB0byByZXRyb2FjdGl2ZWx5IGltcG9zZSB1bm5lY2Vzc2FyeSByZXF1aXJlbWVudHMgb24gZXhp
c3RpbmcgZGVwbG95bWVudHMgaXMgdW5saWtlbHkgdG8gc3VjY2VlZCBhbmQgd2lsbCBzaWduaWZp
Y2FudGx5IHJlZHVjZSB0aGUgcmVsZXZhbmNlIG9mIHRoZSBPQXV0aCAyLjEgZWZmb3J0Ljwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkluIHBhcnRpY3VsYXIsIGF1dGhv
cml6YXRpb24gc2VydmVycyBzaG91bGRu4oCZdCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IFBLQ0Ug
d2hlbiB0aGV5IGFscmVhZHkgc3VwcG9ydCB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuJm5ic3A7
IEFuZCBjbGllbnRzIHNob3VsZG7igJl0DQogcmVqZWN0IHJlc3BvbnNlcyBmcm9tIHNlcnZlcnMg
dGhhdCBkb27igJl0IHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgZG8gY29udGFpbiB0aGUgT3BlbklE
IENvbm5lY3Qgbm9uY2UuJm5ic3A7IERvaW5nIHNvIHdvdWxkIHVubmVjZXNzYXJpbHkgYnJlYWsg
dGhpbmdzIGFuZCBjcmVhdGUgY29uZnVzaW9uIGluIHRoZSBtYXJrZXRwbGFjZS48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDs8YSBocmVmPSJt
YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5EaWNrIEhhcmR0PGJyPg0K
PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAgMTA6NDggQU08YnI+DQo8Yj5Ubzo8
L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRo
QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAt
IHJlcXVpcmUgUEtDRT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5IZWxsbyE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5XZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4x
IGNvZGUgZmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBu
b3QgY29tbW9uIGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBz
b21lIG9mIHRoZSBpc3N1ZXMNCiB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsg
dGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1
dGggMi4wLCBhbmQgaGVuY2UmbmJzcDtoYXZlIHN1cHBvcnQgZm9yIFBLQ0UgaWYgZm9sbG93aW5n
IGJlc3QgcHJhY3RpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+VGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
LSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlv
bnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NFPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHJlZHVjZWQgYXR0YWNrIHN1
cmZhY2Ugd2hlbiB1c2luZyZuYnNwOyBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlm
aWVyIGlzIHNlbnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0
IHZhbHVlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4tIGVuZm9yY2VtZW50IGJ5IEFTIG5vdCBjbGllbnQgLSBtYWtlcyBpdCBlYXNpZXIg
dG8gaGFuZGxlIGZvciBjbGllbnQgZGV2ZWxvcGVycyBhbmQgQVMgY2FuIGVuc3VyZSB0aGUgY2hl
Y2sgaXMgY29uZHVjdGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5XaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVu
dGlhbCBpbXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2Fu
dCBpcyB0aGF0IGltcGFjdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkRpY2ssIEFhcm9uLCBhbmQgVG9yc3RlbjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZv
b2dhZS4uYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUz
RCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD00NTI0MzhiYS1kNDI5LTQ2NTYtYWNlOS1i
Mjg0NzQ0YmMxNzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg
bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy
Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA
aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo
QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojMjIyMjIyIj5WZW5ubGlnIGhpbHNlbjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6
IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+U3RlaW5hciBOb2VtPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMyMjIyMjIiPlBhcnRuZXIgVWRlbHQgQVM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIy
MiI+U3lzdGVtdXR2aWtsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPnwmbmJzcDs8YSBocmVmPSJtYWlsdG86c3RlaW5h
ckB1ZGVsdC5ubyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO2Jh
Y2tncm91bmQ6I0ZGRkZDQyI+c3RlaW5hckB1ZGVsdC5ubzwvc3Bhbj48L2E+Jm5ic3A7fCZuYnNw
OzxhIGhyZWY9Im1haWx0bzpoZWlAdWRlbHQubm8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls
ZT0iY29sb3I6IzExNTVDQyI+aGVpQHVkZWx0Lm5vPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDt8Jm5i
c3A7JiM0Mzs0Nw0KIDk1NSAyMSA2MjAmbmJzcDt8Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy51
ZGVsdC5uby8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQyI+d3d3
LnVkZWx0Lm5vPC9zcGFuPjwvYT4mbmJzcDt8Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_CH2PR00MB067972AFDBBCB149BD27B136F5A40CH2PR00MB0679namp_--


From nobody Wed May  6 13:15:54 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0A3A0AFC for ; Wed,  6 May 2020 13:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2US8gR8tsy6K for ; Wed,  6 May 2020 13:15:45 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00D23A09A1 for ; Wed,  6 May 2020 13:15:45 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id a32so1500288pje.5 for ; Wed, 06 May 2020 13:15:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=OS5feHGdmIgT5o0+lo9E5a2E+WGbPx5Ez6D2FnH25VE=; b=mIS+3Djf0tSWvkqKqnS52XBFJNFl2dvBv3cUuik/CgmpvZj0mAFIuejhVVdyn+FaKK cAfCXc9aqxpXj+lhN8Icev2J9Ak+OZBVN8QBoDvV8Mi9gz9CYCUYMr681Qy9G9muy5bR L5sYwyPgMpxQGuoXG2J4Wmw6OiEmR1u4dKEgHC9PvE6y+q5PMClXDKMTnObdI1rTjXiJ O2stP1r8HdVEk1B6NkOnsFJmO6mwnnPM/vIaqH5sL5cvXa2azeJT4s0194QqVW3fSGUs SE19HP/astYy3o+qaiEYIVJaF6Z6jrzjU8ND3dtVLiNoWxFAaiPtdhbcARId5zCoY7GL Y+jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=OS5feHGdmIgT5o0+lo9E5a2E+WGbPx5Ez6D2FnH25VE=; b=rh7R433tnA+1s0ZUi/x9EA9Qi9WUZBXUBlTQFOsv1pNl/vbcExP69torWMhUgLRnUw s4P/iaR+9m24s3bgHmc71nPCKPXWh7+oXdDm2yLoOTr9YnAQhyOay9w+poVUv8OCp7pC mZCwW/xy1RfLs1AUPrExBCdPx2/+OkwL8+UJLTIn94ZX+WTOLy4gmmzINYB2nmVbHkyj 1pOxmDJAEFCTuDX+pUg+CxLLY09DcF3d/bCKz0xsoNdG6/AVjFq6oYRNjltCidNAXpJa 0JxmygfaBY4OBhXVmcHcpwaXyHt6QAPGIKiAb/SDAnbZBdgmEa9eM4id5iDiWy/Lsbms h/Yg==
X-Gm-Message-State: AGi0PuZbB3stkTkCYWKdPTZg4+SwWEPx/8H3pGlkTJPRcm+qZwouW5U0 La6TBCWaR2pBd8vPCYmxGKQ2Ew==
X-Google-Smtp-Source: APiQypJs8QtTf2E9wBS1+1GyiqWNwWGgGYgAamCd+17ms6cDF2E0O8KZX9h98plRiGSZ+CcDM4Kp3w==
X-Received: by 2002:a17:902:108:: with SMTP id 8mr10239358plb.200.1588796144499;  Wed, 06 May 2020 13:15:44 -0700 (PDT)
Received: from ?IPv6:2001:569:7a71:1d00:d0b7:1f8b:13df:9549? (node-1w7jr9qrfoxxap5gmp3r27uq1.ipv6.telus.net. [2001:569:7a71:1d00:d0b7:1f8b:13df:9549]) by smtp.gmail.com with ESMTPSA id j13sm5807877pje.1.2020.05.06.13.15.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 13:15:43 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-260D757B-DCA6-4D35-9DF4-179EBC716055
Content-Transfer-Encoding: 7bit
From: Phillip Hunt 
Mime-Version: 1.0 (1.0)
Date: Wed, 6 May 2020 13:15:43 -0700
Message-Id: 
References: 
Cc: Aaron Parecki , Steinar Noem , "oauth@ietf.org" 
In-Reply-To: 
To: Mike Jones 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 20:15:52 -0000

--Apple-Mail-260D757B-DCA6-4D35-9DF4-179EBC716055
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Why couldn=E2=80=99t OIDC evolve as a spec to conform and match FAPI and 2.1=
? =20

Phil

> On May 6, 2020, at 12:34 PM, Mike Jones  wrot=
e:
>=20
> =EF=BB=BF
> Yes, FAPI requires PKCE, which is great.  Many of its requirements come fr=
om OpenID Connect but some of them are intentionally incompatible =E2=80=93 s=
uch as requiring that Basic authentication not be supported, whereas Connect=
 requires that it be supported.  It=E2=80=99s a different ecosystem with dif=
ferent requirements.
> =20
> Don=E2=80=99t get me wrong, I support PKCE where it makes sense, such as w=
hen you=E2=80=99re doing bare OAuth without OpenID Connect.  But trying to i=
mpose an unnecessary requirement on a working and secure ecosystem will just=
 create grief for us and our customers and lessen our credibility as steward=
s of the OAuth ecosystem.
> =20
>                                                        -- Mike
> =20
> From: Aaron Parecki =20
> Sent: Wednesday, May 6, 2020 12:29 PM
> To: Steinar Noem 
> Cc: Phillip Hunt ; Mike Jones ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
> =20
> I should add that even some OpenID Connect profiles require PKCE, such as =
FAPI:
> =20
> https://openid.net/specs/openid-financial-api-part-1.html#authorization-se=
rver
> =20
> So the precedent for requiring PKCE already exists within some OpenID Conn=
ect profiles.
> =20
> On Wed, May 6, 2020 at 12:23 PM Aaron Parecki  wrote:
> Yes, and also, many of those providers very likely already support PKCE al=
ready. Skimming through that list of certified OPs, I recognize many names t=
here from providers that I know support PKCE.
> =20
> On Wed, May 6, 2020 at 12:18 PM Steinar Noem  wrote:
> So, wouldn't a MUST just mean that we would have some OPs that are 2.1 com=
pliant and some that aren't?
> =20
> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt :
> Mike,
> =20
> The point of 2.1 is to raise the security bar..=20
> =20
> Yes it adds new MUST requirements.=20
> =20
> But what about OIDC would break other than required implementation of PKCE=
 to support 2.1?
> =20
> Eg Would additional signaling be required to facilitate interoperability a=
nd migration between versions? Would that be an oauth issue or an OIDC one?
> =20
> Phil
>=20
>=20
> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>=20
> =EF=BB=BF
> > In particular, authorization servers shouldn=E2=80=99t be required to su=
pport PKCE when they already support the OpenID Connect nonce.
> =20
> The Security BCP already requires that ASs support PKCE: https://tools.iet=
f.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 Are you suggest=
ing that the Security BCP change that requirement as well? If so, that's a d=
iscussion that needs to be had ASAP. If not, then that's an implicit stateme=
nt that it's okay for OpenID Connect implementations to not be best-practice=
 OAuth implementations. And if that's the case, then I also think it's accep=
table that they are not complete OAuth 2.1 implementations either.
> =20
> =20
> =20
> =20
> =20
> =20
> On Wed, May 6, 2020 at 11:21 AM Mike Jones  wrote:
> The disadvantage of requiring PKCE for OpenID Connect implementations is t=
hat you=E2=80=99re trying to add a normative requirement that=E2=80=99s not r=
equired of OpenID Connect deployments today, which would bifurcate the ecosy=
stem.  There are hundreds of implementations (including the 141 certified on=
es at https://openid.net/certification/), none of which have ever been requi=
red to support PKCE.  Therefore, most don=E2=80=99t.
> =20
> Per feedback already provided, I believe that OAuth 2.1 should align with t=
he guidance already in the draft Security BCP, requiring EITHER the use of P=
KCE or the OpenID Connect nonce.  Trying to retroactively impose unnecessary=
 requirements on existing deployments is unlikely to succeed and will signif=
icantly reduce the relevance of the OAuth 2.1 effort.
> =20
> In particular, authorization servers shouldn=E2=80=99t be required to supp=
ort PKCE when they already support the OpenID Connect nonce.  And clients sh=
ouldn=E2=80=99t reject responses from servers that don=E2=80=99t support PKC=
E when they do contain the OpenID Connect nonce.  Doing so would unnecessari=
ly break things and create confusion in the marketplace.
> =20
>                                                           -- Mike
> =20
> From: OAuth  On Behalf Of Dick Hardt
> Sent: Wednesday, May 6, 2020 10:48 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?
> =20
> Hello!
> =20
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best=
 practice for OAuth 2.0. It is not common in OpenID Connect servers as the n=
once solves some of the issues that PKCE protects against. We think that mos=
t OpenID Connect implementations also support OAuth 2.0, and hence have supp=
ort for PKCE if following best practices.
> =20
> The advantages or requiring PKCE are:
> =20
> - a simpler programming model across all OAuth applications and profiles a=
s they all use PKCE
> =20
> - reduced attack surface when using  S256 as a fingerprint of the verifier=
 is sent through the browser instead of the clear text value
> =20
> - enforcement by AS not client - makes it easier to handle for client deve=
lopers and AS can ensure the check is conducted
> =20
> What are disadvantages besides the potential impact to OpenID Connect depl=
oyments? How significant is that impact?
> =20
> Dick, Aaron, and Torsten
> =20
> =E1=90=A7
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing 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
> --
> Vennlig hilsen
> =20
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
> =20
> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |=20

--Apple-Mail-260D757B-DCA6-4D35-9DF4-179EBC716055
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Why couldn=E2=80=99t OIDC evolve as a spec t=
o conform and match FAPI and 2.1?  

Phil
<=
div dir=3D"ltr">
On May 6, 2020, at 12:34 PM, M=
ike Jones <Michael.Jones@microsoft.com> wrote:

=EF=BB=BF









Yes, FAPI requires PKCE=
, which is great.  Many of its requirements come from OpenID Connect bu=
t some of them are intentionally incompatible =E2=80=93 such as requiring th=
at Basic authentication not be supported, whereas
 Connect requires that it be supported.  It=E2=80=99s a different ecosy=
stem with different requirements.


 


Don=E2=80=99t get me wr=
ong, I support PKCE where it makes sense, such as when you=E2=80=99re doing b=
are OAuth without OpenID Connect.  But trying to impose an unnecessary r=
equirement on a working and secure ecosystem will just
 create grief for us and our customers and lessen our credibility as steward=
s of the OAuth ecosystem.


 


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


 




From: Aaron Parecki <aaron@parecki.com> <=
br>
Sent: Wednesday, May 6, 2020 12:29 PM

To: Steinar Noem <steinar@udelt.no>

Cc: Phillip Hunt <phil.hunt@independentid.com>; Mike Jones <=
Michael.Jones@microsoft.com>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




 




I should add that even some OpenID Connect profiles r=
equire PKCE, such as FAPI:




 







 






So the precedent for requiring PKCE already exists wi=
thin some OpenID Connect profiles.






 






On Wed, May 6, 2020 at 12:23 PM Aaron Parecki <aaron@parecki.com> wrote:=









Yes, and also, many of those providers very likely al=
ready support PKCE already. Skimming through that list of certified OPs, I r=
ecognize many names there from providers that I know support PKCE.




 






On Wed, May 6, 2020 at 12:18 PM Steinar Noem <steinar@udelt.no> w=
rote:








So, wouldn't a MUST just mean that we would have some=
 OPs that are 2.1 compliant and some that aren't?




 






ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt <phil.hunt@indep=
endentid.com>:








Mike,




 






The point of 2.1 is to raise the security bar.. =







 






Yes it adds new MUST requirements. 





 






But what about OIDC would break other than required i=
mplementation of PKCE to support 2.1?






 






Eg Would additional signaling be required to facilita=
te interoperability and migration between versions? Would that be an oauth i=
ssue or an OIDC one?






 








Phil















On May 6, 2020, at 11:=
56 AM, Aaron Parecki <aaron@parecki.com> wrote:










=EF=BB=BF






> In particular, authorization servers shouldn=E2=80=
=99t be required to support PKCE when they already support the OpenID Connec=
t nonce.






 






The Security BCP already requires that ASs support PK=
CE: https://tools.ietf.org/html/draft-i=
etf-oauth-security-topics-15#section-2.1.1 Are
 you suggesting that the Security BCP change that requirement as well? If so=
, that's a discussion that needs to be had ASAP. If not, then that's an impl=
icit statement that it's okay for OpenID Connect implementations to not be b=
est-practice OAuth implementations.
 And if that's the case, then I also think it's acceptable that they are not=
 complete OAuth 2.1 implementations either.






 






 




 






 




 










 






On Wed, May 6, 2020 at 11:21 AM Mike Jones <Michae=
l.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:










The disadvantage of requiring PKCE for=
 OpenID Connect implementations is that you=E2=80=99re trying to add a norma=
tive requirement that=E2=80=99s not required of OpenID
 Connect deployments today, which would bifurcate the ecosystem.  There=
 are hundreds of implementations (including the 141 certified ones at
https://openid.net/certification/), none of which have ever been required to support PKCE.  Therefo=
re, most don=E2=80=99t.


 


Per feedback already provided, I belie=
ve that OAuth 2.1 should align with the guidance already in the draft Securi=
ty BCP, requiring EITHER the use of
 PKCE or the OpenID Connect nonce.  Trying to retroactively impose unne=
cessary requirements on existing deployments is unlikely to succeed and will=
 significantly reduce the relevance of the OAuth 2.1 effort.


 


In particular, authorization servers s=
houldn=E2=80=99t be required to support PKCE when they already support the O=
penID Connect nonce.  And clients shouldn=E2=80=99t
 reject responses from servers that don=E2=80=99t support PKCE when they do c=
ontain the OpenID Connect nonce.  Doing so would unnecessarily break th=
ings and create confusion in the marketplace.


 


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


 




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.or=
g

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




 






Hello!




 






We would like to have PKCE be a MUST in OAuth 2.1 code flows. This i=
s best practice for OAuth 2.0. It is not common in OpenID Connect servers as=
 the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementatio=
ns also support OAuth 2.0, and hence have support for PKCE if following=
 best practices.






 






The advantages or requiring PKCE are:






 






- a simpler programming model across all OAuth applications and prof=
iles as they all use PKCE






 






- reduced attack surface when using  S256 as a fingerprint of t=
he verifier is sent through the browser instead of the clear text value=







 






- enforcement by AS not client - makes it easier to handle for clien=
t developers and AS can ensure the check is conducted






 






What are disadvantages besides the potential impact to OpenID Connec=
t deployments? How significant is that impact?






 






Dick, Aaron, and Torsten






 










=
=E1=90=A7








_______________________________________________

OAuth mailing list

OAuth@ietf.org

ht=
tps://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

ht=
tps://www.ietf.org/mailman/listinfo/oauth













 




-- 












Vennlig hilsen






 

























=

--Apple-Mail-260D757B-DCA6-4D35-9DF4-179EBC716055--


From nobody Wed May  6 13:39:27 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C203A0B0C for ; Wed,  6 May 2020 13:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVcr7V02h0C2 for ; Wed,  6 May 2020 13:39:23 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640123.outbound.protection.outlook.com [40.107.64.123]) (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 A6D073A0B0E for ; Wed,  6 May 2020 13:39:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OEGwVLEjaQ/HvnLKam4mrsoVZgKuv+ZkQU3/DfKyQV3VXTbmiI0NruBetPRUQFgepABg+sGA22T9rxIeD4KPAZZ0LGd9Fs4xKMecyDhFwC1rI6PyJ/PpWFbfzg67oT/KLf2LoMc8cNJCxgPDDK1/ROI8Y804PNsWJAVHePlrQDv0DMNKXq5A+AHly+xd7gwd8Pk5wtdknt2qeQxWQpgb35/8N5V/5gIRNY2AoSCuJFmi2e2/poD248zcDuz/gdRVewEDcPwR6GeMFuwtsZVZcpWHnq1pmXfMb2HNLZcLPs4druaKJyXZF0FI58/RsFwf0yqP3DEvYaMa219U5DFDPg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8bNSmi5iF43kffgqXQh7zi4wOeqxkF3/QykFh3UeNhw=; b=jg4V9YSoThWhWOf9wOJm06sleioqWDOHVoONRmI83VJaENjnavPJcVzh37B5wdymRDuffQS/2xnYIMU0ThiCw3tDdxaOlQyOrq7hQrxsWwVl5kBa5xfyLPQ5qY7VEKuHitWJ5k3k/JUdNctHBAucgx0y6BuwIpihwJS7iUAg9UrsGRC6Isy06cFWG6lSjjQ+jCDffZ8Ofhw6+HLYj9t2nRiigqSs9/BGAsBdfSvDVweOkl1fZmP0QCu4LHOTd0dgq49Bq8zBFfxrSg4kw//BgvAGzCW3MlZCRSNjAgenTdT0F5xnAR+NzKcsfQUqTQ8tTkpn39faLHdTWaygq22RsA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8bNSmi5iF43kffgqXQh7zi4wOeqxkF3/QykFh3UeNhw=; b=Yh7w9nSzh1MIwZ5UweZ1p0n1QC6wog5PBmSikP+g9mRlXQvk67o55w7NdgcGd7qPSPfRt4rg/QggSi7UTyit3THbSm2IeptfRd30iwkXMPU6NfUQrETTsfNdDQA2pMpoEg0pPw6QQrtu8EEBUNnhgwWVnOrUnANYh6+YWJcT53k=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0841.namprd00.prod.outlook.com (2603:10b6:610:6f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3012.0; Wed, 6 May 2020 20:39:20 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8%9]) with mapi id 15.20.3015.000; Wed, 6 May 2020 20:39:20 +0000
From: Mike Jones 
To: Phillip Hunt 
CC: Aaron Parecki , Steinar Noem , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYj5mo5/cX2OW7CQoCZ/yIhAVjibg==
Date: Wed, 6 May 2020 20:39:20 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5d029ee2-9f74-4f68-af22-0000f3f2c840; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T20:36:56Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: independentid.com; dkim=none (message not signed) header.d=none;independentid.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 34bf98a5-830a-45d0-6ad8-08d7f1fd8dea
x-ms-traffictypediagnostic: CH2PR00MB0841:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: fnWqKxveQw2Fn9DMDIJ0nVwcLORtZhcNbgs2VsnMIiZfjSyI6RtfIiOneu/XGrqwdakYxe9wdGUtoxTn1n7pMzkTbFAzLsgfQr2XsMMiRTKIqx2bd5jNBfWkxdSQVIEAaQmf/PRMDXQ3Y2O3Zz1ecb1WlXls/A6q5nTaq4adVFdAjYnTJClntz0Zrch1KSuo/WEpM+/ZaO5eobzAuEH9P2nNreFlG8gYIzNZ+RS4B2TOkVVLWixJVAolq9uSZ4E0df3EIKCUJcpcvbZhJb2vDtiio0l8+nk7JFWN1EDwoSEuOe+Kj/vV6eR8dLYG8t8R8zMhzrGlJuIgj1PV7i0DsbbUhdOonXrzVaWOW7OzNnRnqZb6ks2t4NdB+bZLwlte/bcAIUMyCfBG0tM1WVngcn/ulpwKspl7NpaRHvu71Y0UeOmY2tm8x8rgrSuTDTDLKYnLuXWRNdDRPsfFXwokfBuG1bGR57BiII3Hj6qKCf7almiymAJfE6OkMngZOre7YYA8+7g5WqzGC1CPPtBqKA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(33430700001)(26005)(7696005)(186003)(55016002)(64756008)(82960400001)(82950400001)(66446008)(10290500003)(76116006)(966005)(66574014)(9686003)(66476007)(4326008)(6506007)(8990500004)(66946007)(478600001)(2906002)(33440700001)(53546011)(66556008)(5660300002)(6916009)(8676002)(316002)(8936002)(54906003)(166002)(71200400001)(33656002)(52536014)(86362001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: PEUHgZNwI9fWcUPpbmsC6szEMaJUz8V/ocAv1FcS0a4pes+TC0SHOwgISlxgMsoazMJzaeRNpPLy5ykGa7pChavI2kARDBG+BJAtctk4DhNysaoHWCApQ5Nf7o00o/unvXD5mpIDi8Lq5j3Hc+YojjtfT+lCv3o5PRnN8kPcvUZVEKO279LYAez1Li2jOIn6WCXLfOU4aVcJj/nOxffJwGwwRgGDgjBslM5xLXmN1seoJax6m/hHRaP1fAr/PzP4OGNnJ+pTbxoXcu8Ng80l4pUtje8z43nVeZVw9qqCcO9Fg6KqMe+ViIJ4nCmIh7Fy2teb8d16A68kH3GFRME9DHbf0LNBxY+2buwL6YM2vvd+LCbERLYagvApmqpNKbezryyKmQJDelhDNJ+K09zViCIbQLUQsgwhUrt1QZ3PO0u0Umnp7y73UXlD8btfglrXGq+6vPlX9BGKoCo9SUDqDZj3M6Zf9YZ6CX9sk0C95GvNJZjYQ+Irl1hnukt9k8KVFgA/C2DAp1fDvf1AIxGmSU/VdMfUTfOCIHrSmmskyiqYJia60N4PlvSKu3woNBxXeVB2g1YMAdeIeC5YH/VTl9WdarUMmdBjRxjUKqRFZFUMULbgxZtMutlMw32KmLYTbOhKrxhtaMBP+hhxS1gCaSiCBBSGZuofPnr06TcxMePSGSFOzpQIvQyNKLkSVmv3LB6KP1rYYKQmJBstJOPSMfXcM/5p/wXkdIvIBuapWMr9qfzImlaPuX1uzpV2iOaRvVhhcsS5lebhKluax9vd4q8dbEGIF+Z+IzHuiXA91rU=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB067920C5AE38FBC1A47E3CE1F5A40CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 34bf98a5-830a-45d0-6ad8-08d7f1fd8dea
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 20:39:20.5199 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HcZ6ezQ/MM8oTTsFo9gMH9r1S0G5bL1k3r50eXpLajK9tVYSmxpVAcBaU67R6qkCkA7tubk6vzPgkHDHcbtVug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0841
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 20:39:26 -0000

--_000_CH2PR00MB067920C5AE38FBC1A47E3CE1F5A40CH2PR00MB0679namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXQgY291bGQsIGJ1dCB0aGF0IHdvdWxkIHJlcXVpcmUgYW4gZXhwbGljaXQgZGVjaXNpb24gYnkg
dGhlIE9wZW5JRCBDb25uZWN0IHdvcmtpbmcgZ3JvdXAgdG8gbWFrZSBleGlzdGluZyBSUHMgaW5j
b21wYXRpYmxlIHdpdGggbmV3IE9QcywgYnJlYWtpbmcgaW50ZXJvcGVyYWJpbGl0eS4gIFRoYXTi
gJlzIG5vdCBhIGRlY2lzaW9uIHdlIHNob3VsZCBtYWtlIGxpZ2h0bHkgb3Igd2l0aG91dCBhIGNv
bXBlbGxpbmcgcmVhc29uIHRvIGRvIHNvLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsbGlwIEh1bnQg
PHBoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDYsIDIw
MjAgMToxNiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4N
CkNjOiBBYXJvbiBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT47IFN0ZWluYXIgTm9lbSA8c3Rl
aW5hckB1ZGVsdC5ubz47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBP
QXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/DQoNCldoeSBjb3VsZG7igJl0IE9JREMgZXZvbHZlIGFz
IGEgc3BlYyB0byBjb25mb3JtIGFuZCBtYXRjaCBGQVBJIGFuZCAyLjE/DQpQaGlsDQoNCg0KT24g
TWF5IDYsIDIwMjAsIGF0IDEyOjM0IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv
c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K77u/
DQpZZXMsIEZBUEkgcmVxdWlyZXMgUEtDRSwgd2hpY2ggaXMgZ3JlYXQuICBNYW55IG9mIGl0cyBy
ZXF1aXJlbWVudHMgY29tZSBmcm9tIE9wZW5JRCBDb25uZWN0IGJ1dCBzb21lIG9mIHRoZW0gYXJl
IGludGVudGlvbmFsbHkgaW5jb21wYXRpYmxlIOKAkyBzdWNoIGFzIHJlcXVpcmluZyB0aGF0IEJh
c2ljIGF1dGhlbnRpY2F0aW9uIG5vdCBiZSBzdXBwb3J0ZWQsIHdoZXJlYXMgQ29ubmVjdCByZXF1
aXJlcyB0aGF0IGl0IGJlIHN1cHBvcnRlZC4gIEl04oCZcyBhIGRpZmZlcmVudCBlY29zeXN0ZW0g
d2l0aCBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzLg0KDQpEb27igJl0IGdldCBtZSB3cm9uZywgSSBz
dXBwb3J0IFBLQ0Ugd2hlcmUgaXQgbWFrZXMgc2Vuc2UsIHN1Y2ggYXMgd2hlbiB5b3XigJlyZSBk
b2luZyBiYXJlIE9BdXRoIHdpdGhvdXQgT3BlbklEIENvbm5lY3QuICBCdXQgdHJ5aW5nIHRvIGlt
cG9zZSBhbiB1bm5lY2Vzc2FyeSByZXF1aXJlbWVudCBvbiBhIHdvcmtpbmcgYW5kIHNlY3VyZSBl
Y29zeXN0ZW0gd2lsbCBqdXN0IGNyZWF0ZSBncmllZiBmb3IgdXMgYW5kIG91ciBjdXN0b21lcnMg
YW5kIGxlc3NlbiBvdXIgY3JlZGliaWxpdHkgYXMgc3Rld2FyZHMgb2YgdGhlIE9BdXRoIGVjb3N5
c3RlbS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb208
bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPj4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAg
MTI6MjkgUE0NClRvOiBTdGVpbmFyIE5vZW0gPHN0ZWluYXJAdWRlbHQubm88bWFpbHRvOnN0ZWlu
YXJAdWRlbHQubm8+Pg0KQ2M6IFBoaWxsaXAgSHVudCA8cGhpbC5odW50QGluZGVwZW5kZW50aWQu
Y29tPG1haWx0bzpwaGlsLmh1bnRAaW5kZXBlbmRlbnRpZC5jb20+PjsgTWlrZSBKb25lcyA8TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20+Pjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPw0KDQpJIHNob3VsZCBhZGQgdGhh
dCBldmVuIHNvbWUgT3BlbklEIENvbm5lY3QgcHJvZmlsZXMgcmVxdWlyZSBQS0NFLCBzdWNoIGFz
IEZBUEk6DQoNCmh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtZmluYW5jaWFsLWFwaS1w
YXJ0LTEuaHRtbCNhdXRob3JpemF0aW9uLXNlcnZlcg0KDQpTbyB0aGUgcHJlY2VkZW50IGZvciBy
ZXF1aXJpbmcgUEtDRSBhbHJlYWR5IGV4aXN0cyB3aXRoaW4gc29tZSBPcGVuSUQgQ29ubmVjdCBw
cm9maWxlcy4NCg0KT24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMjoyMyBQTSBBYXJvbiBQYXJlY2tp
IDxhYXJvbkBwYXJlY2tpLmNvbTxtYWlsdG86YWFyb25AcGFyZWNraS5jb20+PiB3cm90ZToNClll
cywgYW5kIGFsc28sIG1hbnkgb2YgdGhvc2UgcHJvdmlkZXJzIHZlcnkgbGlrZWx5IGFscmVhZHkg
c3VwcG9ydCBQS0NFIGFscmVhZHkuIFNraW1taW5nIHRocm91Z2ggdGhhdCBsaXN0IG9mIGNlcnRp
ZmllZCBPUHMsIEkgcmVjb2duaXplIG1hbnkgbmFtZXMgdGhlcmUgZnJvbSBwcm92aWRlcnMgdGhh
dCBJIGtub3cgc3VwcG9ydCBQS0NFLg0KDQpPbiBXZWQsIE1heSA2LCAyMDIwIGF0IDEyOjE4IFBN
IFN0ZWluYXIgTm9lbSA8c3RlaW5hckB1ZGVsdC5ubzxtYWlsdG86c3RlaW5hckB1ZGVsdC5ubz4+
IHdyb3RlOg0KU28sIHdvdWxkbid0IGEgTVVTVCBqdXN0IG1lYW4gdGhhdCB3ZSB3b3VsZCBoYXZl
IHNvbWUgT1BzIHRoYXQgYXJlIDIuMSBjb21wbGlhbnQgYW5kIHNvbWUgdGhhdCBhcmVuJ3Q/DQoN
Cm9ucy4gNi4gbWFpIDIwMjAga2wuIDIxOjEyIHNrcmV2IFBoaWxsaXAgSHVudCA8cGhpbC5odW50
QGluZGVwZW5kZW50aWQuY29tPG1haWx0bzpwaGlsLmh1bnRAaW5kZXBlbmRlbnRpZC5jb20+PjoN
Ck1pa2UsDQoNClRoZSBwb2ludCBvZiAyLjEgaXMgdG8gcmFpc2UgdGhlIHNlY3VyaXR5IGJhci4u
DQoNClllcyBpdCBhZGRzIG5ldyBNVVNUIHJlcXVpcmVtZW50cy4NCg0KQnV0IHdoYXQgYWJvdXQg
T0lEQyB3b3VsZCBicmVhayBvdGhlciB0aGFuIHJlcXVpcmVkIGltcGxlbWVudGF0aW9uIG9mIFBL
Q0UgdG8gc3VwcG9ydCAyLjE/DQoNCkVnIFdvdWxkIGFkZGl0aW9uYWwgc2lnbmFsaW5nIGJlIHJl
cXVpcmVkIHRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSBhbmQgbWlncmF0aW9uIGJldHdl
ZW4gdmVyc2lvbnM/IFdvdWxkIHRoYXQgYmUgYW4gb2F1dGggaXNzdWUgb3IgYW4gT0lEQyBvbmU/
DQoNClBoaWwNCg0KDQoNCk9uIE1heSA2LCAyMDIwLCBhdCAxMTo1NiBBTSwgQWFyb24gUGFyZWNr
aSA8YWFyb25AcGFyZWNraS5jb208bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPj4gd3JvdGU6DQrv
u78NCj4gSW4gcGFydGljdWxhciwgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZG7igJl0IGJl
IHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgYWxyZWFkeSBzdXBwb3J0IHRoZSBP
cGVuSUQgQ29ubmVjdCBub25jZS4NCg0KVGhlIFNlY3VyaXR5IEJDUCBhbHJlYWR5IHJlcXVpcmVz
IHRoYXQgQVNzIHN1cHBvcnQgUEtDRTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24tMi4xLjEgQXJlIHlvdSBzdWdn
ZXN0aW5nIHRoYXQgdGhlIFNlY3VyaXR5IEJDUCBjaGFuZ2UgdGhhdCByZXF1aXJlbWVudCBhcyB3
ZWxsPyBJZiBzbywgdGhhdCdzIGEgZGlzY3Vzc2lvbiB0aGF0IG5lZWRzIHRvIGJlIGhhZCBBU0FQ
LiBJZiBub3QsIHRoZW4gdGhhdCdzIGFuIGltcGxpY2l0IHN0YXRlbWVudCB0aGF0IGl0J3Mgb2th
eSBmb3IgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIHRvIG5vdCBiZSBiZXN0LXByYWN0
aWNlIE9BdXRoIGltcGxlbWVudGF0aW9ucy4gQW5kIGlmIHRoYXQncyB0aGUgY2FzZSwgdGhlbiBJ
IGFsc28gdGhpbmsgaXQncyBhY2NlcHRhYmxlIHRoYXQgdGhleSBhcmUgbm90IGNvbXBsZXRlIE9B
dXRoIDIuMSBpbXBsZW1lbnRhdGlvbnMgZWl0aGVyLg0KDQoNCg0KDQoNCg0KT24gV2VkLCBNYXkg
NiwgMjAyMCBhdCAxMToyMSBBTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0
LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn
Pj4gd3JvdGU6DQpUaGUgZGlzYWR2YW50YWdlIG9mIHJlcXVpcmluZyBQS0NFIGZvciBPcGVuSUQg
Q29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgaXMgdGhhdCB5b3XigJlyZSB0cnlpbmcgdG8gYWRkIGEg
bm9ybWF0aXZlIHJlcXVpcmVtZW50IHRoYXTigJlzIG5vdCByZXF1aXJlZCBvZiBPcGVuSUQgQ29u
bmVjdCBkZXBsb3ltZW50cyB0b2RheSwgd2hpY2ggd291bGQgYmlmdXJjYXRlIHRoZSBlY29zeXN0
ZW0uICBUaGVyZSBhcmUgaHVuZHJlZHMgb2YgaW1wbGVtZW50YXRpb25zIChpbmNsdWRpbmcgdGhl
IDE0MSBjZXJ0aWZpZWQgb25lcyBhdCBodHRwczovL29wZW5pZC5uZXQvY2VydGlmaWNhdGlvbi8p
LCBub25lIG9mIHdoaWNoIGhhdmUgZXZlciBiZWVuIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRS4g
IFRoZXJlZm9yZSwgbW9zdCBkb27igJl0Lg0KDQpQZXIgZmVlZGJhY2sgYWxyZWFkeSBwcm92aWRl
ZCwgSSBiZWxpZXZlIHRoYXQgT0F1dGggMi4xIHNob3VsZCBhbGlnbiB3aXRoIHRoZSBndWlkYW5j
ZSBhbHJlYWR5IGluIHRoZSBkcmFmdCBTZWN1cml0eSBCQ1AsIHJlcXVpcmluZyBFSVRIRVIgdGhl
IHVzZSBvZiBQS0NFIG9yIHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4gIFRyeWluZyB0byByZXRy
b2FjdGl2ZWx5IGltcG9zZSB1bm5lY2Vzc2FyeSByZXF1aXJlbWVudHMgb24gZXhpc3RpbmcgZGVw
bG95bWVudHMgaXMgdW5saWtlbHkgdG8gc3VjY2VlZCBhbmQgd2lsbCBzaWduaWZpY2FudGx5IHJl
ZHVjZSB0aGUgcmVsZXZhbmNlIG9mIHRoZSBPQXV0aCAyLjEgZWZmb3J0Lg0KDQpJbiBwYXJ0aWN1
bGFyLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkbuKAmXQgYmUgcmVxdWlyZWQgdG8gc3Vw
cG9ydCBQS0NFIHdoZW4gdGhleSBhbHJlYWR5IHN1cHBvcnQgdGhlIE9wZW5JRCBDb25uZWN0IG5v
bmNlLiAgQW5kIGNsaWVudHMgc2hvdWxkbuKAmXQgcmVqZWN0IHJlc3BvbnNlcyBmcm9tIHNlcnZl
cnMgdGhhdCBkb27igJl0IHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgZG8gY29udGFpbiB0aGUgT3Bl
bklEIENvbm5lY3Qgbm9uY2UuICBEb2luZyBzbyB3b3VsZCB1bm5lY2Vzc2FyaWx5IGJyZWFrIHRo
aW5ncyBhbmQgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUgbWFya2V0cGxhY2UuDQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl
DQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFdlZG5lc2RheSwg
TWF5IDYsIDIwMjAgMTA6NDggQU0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0K
SGVsbG8hDQoNCldlIHdvdWxkIGxpa2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAy
LjEgY29kZSBmbG93cy4gVGhpcyBpcyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlz
IG5vdCBjb21tb24gaW4gT3BlbklEIENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVz
IHNvbWUgb2YgdGhlIGlzc3VlcyB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsg
dGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1
dGggMi4wLCBhbmQgaGVuY2UgaGF2ZSBzdXBwb3J0IGZvciBQS0NFIGlmIGZvbGxvd2luZyBiZXN0
IHByYWN0aWNlcy4NCg0KVGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOg0KDQot
IGEgc2ltcGxlciBwcm9ncmFtbWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0aW9u
cyBhbmQgcHJvZmlsZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0UNCg0KLSByZWR1Y2VkIGF0dGFjayBz
dXJmYWNlIHdoZW4gdXNpbmcgIFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZpZXIg
aXMgc2VudCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQgdmFs
dWUNCg0KLSBlbmZvcmNlbWVudCBieSBBUyBub3QgY2xpZW50IC0gbWFrZXMgaXQgZWFzaWVyIHRv
IGhhbmRsZSBmb3IgY2xpZW50IGRldmVsb3BlcnMgYW5kIEFTIGNhbiBlbnN1cmUgdGhlIGNoZWNr
IGlzIGNvbmR1Y3RlZA0KDQpXaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVu
dGlhbCBpbXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2Fu
dCBpcyB0aGF0IGltcGFjdD8NCg0KRGljaywgQWFyb24sIGFuZCBUb3JzdGVuDQoNCltodHRwczov
L21haWxmb29nYWUuLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJD
NWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5LWIy
ODQ3NDRiYzE3MV3hkKcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls
aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCg0KDQotLQ0KVmVubmxpZyBoaWxzZW4NCg0KU3RlaW5hciBOb2Vt
DQpQYXJ0bmVyIFVkZWx0IEFTDQpTeXN0ZW11dHZpa2xlcg0KDQp8IHN0ZWluYXJAdWRlbHQubm88
bWFpbHRvOnN0ZWluYXJAdWRlbHQubm8+IHwgaGVpQHVkZWx0Lm5vPG1haWx0bzpoZWlAdWRlbHQu
bm8+ICB8ICs0NyA5NTUgMjEgNjIwIHwgd3d3LnVkZWx0Lm5vPGh0dHA6Ly93d3cudWRlbHQubm8v
PiB8DQo=

--_000_CH2PR00MB067920C5AE38FBC1A47E3CE1F5A40CH2PR00MB0679namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z
aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JdCBjb3VsZCwgYnV0IHRo
YXQgd291bGQgcmVxdWlyZSBhbiBleHBsaWNpdCBkZWNpc2lvbiBieSB0aGUgT3BlbklEIENvbm5l
Y3Qgd29ya2luZyBncm91cCB0byBtYWtlIGV4aXN0aW5nIFJQcyBpbmNvbXBhdGlibGUgd2l0aCBu
ZXcgT1BzLCBicmVha2luZyBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBUaGF04oCZcyBub3QgYSBk
ZWNpc2lvbiB3ZSBzaG91bGQgbWFrZSBsaWdodGx5DQogb3Igd2l0aG91dCBhIGNvbXBlbGxpbmcg
cmVhc29uIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2
MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBQaGlsbGlwIEh1bnQg
Jmx0O3BoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdl
ZG5lc2RheSwgTWF5IDYsIDIwMjAgMToxNiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAm
bHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQWFyb24g
UGFyZWNraSAmbHQ7YWFyb25AcGFyZWNraS5jb20mZ3Q7OyBTdGVpbmFyIE5vZW0gJmx0O3N0ZWlu
YXJAdWRlbHQubm8mZ3Q7OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldoeSBjb3Vs
ZG7igJl0IE9JREMgZXZvbHZlIGFzIGEgc3BlYyB0byBjb25mb3JtIGFuZCBtYXRjaCBGQVBJIGFu
ZCAyLjE/ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIE1heSA2LCAyMDIwLCBhdCAxMjozNCBQTSwgTWlr
ZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPu+7
vyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj5ZZXMsIEZBUEkgcmVxdWlyZXMgUEtDRSwgd2hpY2ggaXMgZ3JlYXQuJm5ic3A7
IE1hbnkgb2YgaXRzIHJlcXVpcmVtZW50cyBjb21lIGZyb20gT3BlbklEIENvbm5lY3QgYnV0IHNv
bWUgb2YgdGhlbSBhcmUgaW50ZW50aW9uYWxseSBpbmNvbXBhdGlibGUg4oCTIHN1Y2ggYXMgcmVx
dWlyaW5nIHRoYXQgQmFzaWMgYXV0aGVudGljYXRpb24gbm90IGJlIHN1cHBvcnRlZCwgd2hlcmVh
cw0KIENvbm5lY3QgcmVxdWlyZXMgdGhhdCBpdCBiZSBzdXBwb3J0ZWQuJm5ic3A7IEl04oCZcyBh
IGRpZmZlcmVudCBlY29zeXN0ZW0gd2l0aCBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+RG9u4oCZdCBnZXQgbWUgd3JvbmcsIEkgc3Vw
cG9ydCBQS0NFIHdoZXJlIGl0IG1ha2VzIHNlbnNlLCBzdWNoIGFzIHdoZW4geW914oCZcmUgZG9p
bmcgYmFyZSBPQXV0aCB3aXRob3V0IE9wZW5JRCBDb25uZWN0LiZuYnNwOyBCdXQgdHJ5aW5nIHRv
IGltcG9zZSBhbiB1bm5lY2Vzc2FyeSByZXF1aXJlbWVudCBvbiBhIHdvcmtpbmcgYW5kIHNlY3Vy
ZSBlY29zeXN0ZW0gd2lsbCBqdXN0DQogY3JlYXRlIGdyaWVmIGZvciB1cyBhbmQgb3VyIGN1c3Rv
bWVycyBhbmQgbGVzc2VuIG91ciBjcmVkaWJpbGl0eSBhcyBzdGV3YXJkcyBvZiB0aGUgT0F1dGgg
ZWNvc3lzdGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFhcm9uIFBhcmVja2kgJmx0OzxhIGhyZWY9
Im1haWx0bzphYXJvbkBwYXJlY2tpLmNvbSI+YWFyb25AcGFyZWNraS5jb208L2E+Jmd0Ow0KPGJy
Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDYsIDIwMjAgMTI6MjkgUE08YnI+DQo8Yj5U
bzo8L2I+IFN0ZWluYXIgTm9lbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWluYXJAdWRlbHQubm8i
PnN0ZWluYXJAdWRlbHQubm88L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUGhpbGxpcCBIdW50ICZs
dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QGluZGVwZW5kZW50aWQuY29tIj5waGlsLmh1bnRA
aW5kZXBlbmRlbnRpZC5jb208L2E+Jmd0OzsgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv
Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1
aXJlIFBLQ0U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2hvdWxk
IGFkZCB0aGF0IGV2ZW4gc29tZSBPcGVuSUQgQ29ubmVjdCBwcm9maWxlcyByZXF1aXJlIFBLQ0Us
IHN1Y2ggYXMgRkFQSTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtZmluYW5jaWFsLWFw
aS1wYXJ0LTEuaHRtbCNhdXRob3JpemF0aW9uLXNlcnZlciI+aHR0cHM6Ly9vcGVuaWQubmV0L3Nw
ZWNzL29wZW5pZC1maW5hbmNpYWwtYXBpLXBhcnQtMS5odG1sI2F1dGhvcml6YXRpb24tc2VydmVy
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5TbyB0aGUgcHJlY2VkZW50IGZvciByZXF1aXJpbmcgUEtDRSBhbHJlYWR5IGV4aXN0cyB3aXRo
aW4gc29tZSBPcGVuSUQgQ29ubmVjdCBwcm9maWxlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMjoy
MyBQTSBBYXJvbiBQYXJlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20i
PmFhcm9uQHBhcmVja2kuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYW5kIGFsc28sIG1hbnkgb2YgdGhvc2UgcHJvdmlk
ZXJzIHZlcnkgbGlrZWx5IGFscmVhZHkgc3VwcG9ydCBQS0NFIGFscmVhZHkuIFNraW1taW5nIHRo
cm91Z2ggdGhhdCBsaXN0IG9mIGNlcnRpZmllZCBPUHMsIEkgcmVjb2duaXplIG1hbnkgbmFtZXMg
dGhlcmUgZnJvbSBwcm92aWRlcnMgdGhhdCBJIGtub3cgc3VwcG9ydCBQS0NFLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgNiwgMjAyMCBh
dCAxMjoxOCBQTSBTdGVpbmFyIE5vZW0gJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVpbmFyQHVkZWx0
Lm5vIiB0YXJnZXQ9Il9ibGFuayI+c3RlaW5hckB1ZGVsdC5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tbywgd291bGRuJ3QgYSBN
VVNUIGp1c3QgbWVhbiB0aGF0IHdlIHdvdWxkIGhhdmUgc29tZSBPUHMgdGhhdCBhcmUgMi4xIGNv
bXBsaWFudCBhbmQgc29tZSB0aGF0IGFyZW4ndD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPm9ucy4gNi4gbWFpIDIwMjAga2wuIDIxOjEyIHNrcmV2IFBoaWxs
aXAgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNvbTwvYT4mZ3Q7OjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW46MC4uOGV4Ij4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhlIHBvaW50IG9mIDIuMSBpcyB0byByYWlzZSB0aGUgc2VjdXJpdHkg
YmFyLi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+WWVzIGl0IGFkZHMgbmV3IE1VU1QgcmVxdWlyZW1lbnRzLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgd2hhdCBh
Ym91dCBPSURDIHdvdWxkIGJyZWFrIG90aGVyIHRoYW4gcmVxdWlyZWQgaW1wbGVtZW50YXRpb24g
b2YgUEtDRSB0byBzdXBwb3J0IDIuMT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+RWcgV291bGQgYWRkaXRpb25hbCBzaWduYWxpbmcgYmUgcmVx
dWlyZWQgdG8gZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5IGFuZCBtaWdyYXRpb24gYmV0d2Vl
biB2ZXJzaW9ucz8gV291bGQgdGhhdCBiZSBhbiBvYXV0aCBpc3N1ZSBvciBhbiBPSURDIG9uZT88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIE1heSA2LCAyMDIwLCBhdCAxMTo1
NiBBTSwgQWFyb24gUGFyZWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhcm9uQHBhcmVja2kuY29t
IiB0YXJnZXQ9Il9ibGFuayI+YWFyb25AcGFyZWNraS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+77u/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZndDsgSW4gcGFydGljdWxhciwgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZG7igJl0
IGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgYWxyZWFkeSBzdXBwb3J0IHRo
ZSBPcGVuSUQgQ29ubmVjdCBub25jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFNlY3VyaXR5IEJDUCBhbHJlYWR5IHJlcXVpcmVzIHRo
YXQgQVNzIHN1cHBvcnQgUEtDRTombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMSIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h
dXRoLXNlY3VyaXR5LXRvcGljcy0xNSNzZWN0aW9uLTIuMS4xPC9hPiZuYnNwO0FyZQ0KIHlvdSBz
dWdnZXN0aW5nIHRoYXQgdGhlIFNlY3VyaXR5IEJDUCBjaGFuZ2UgdGhhdCByZXF1aXJlbWVudCBh
cyB3ZWxsPyBJZiBzbywgdGhhdCdzIGEgZGlzY3Vzc2lvbiB0aGF0IG5lZWRzIHRvIGJlIGhhZCBB
U0FQLiBJZiBub3QsIHRoZW4gdGhhdCdzIGFuIGltcGxpY2l0IHN0YXRlbWVudCB0aGF0IGl0J3Mg
b2theSBmb3IgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIHRvIG5vdCBiZSBiZXN0LXBy
YWN0aWNlIE9BdXRoIGltcGxlbWVudGF0aW9ucy4NCiBBbmQgaWYgdGhhdCdzIHRoZSBjYXNlLCB0
aGVuIEkgYWxzbyB0aGluayBpdCdzIGFjY2VwdGFibGUgdGhhdCB0aGV5IGFyZSBub3QgY29tcGxl
dGUgT0F1dGggMi4xIGltcGxlbWVudGF0aW9ucyBlaXRoZXIuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1heSA2
LCAyMDIwIGF0IDExOjIxIEFNIE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9PGEgaHJlZj0i
bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQw
bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s
b3I6IzAwMjA2MCI+VGhlIGRpc2FkdmFudGFnZSBvZiByZXF1aXJpbmcgUEtDRSBmb3IgT3BlbklE
IENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGlzIHRoYXQgeW914oCZcmUgdHJ5aW5nIHRvIGFkZCBh
IG5vcm1hdGl2ZSByZXF1aXJlbWVudCB0aGF04oCZcyBub3QgcmVxdWlyZWQgb2YgT3BlbklEDQog
Q29ubmVjdCBkZXBsb3ltZW50cyB0b2RheSwgd2hpY2ggd291bGQgYmlmdXJjYXRlIHRoZSBlY29z
eXN0ZW0uJm5ic3A7IFRoZXJlIGFyZSBodW5kcmVkcyBvZiBpbXBsZW1lbnRhdGlvbnMgKGluY2x1
ZGluZyB0aGUgMTQxIGNlcnRpZmllZCBvbmVzIGF0DQo8YSBocmVmPSJodHRwczovL29wZW5pZC5u
ZXQvY2VydGlmaWNhdGlvbi8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw
MjA2MDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9vcGVuaWQubmV0L2NlcnRpZmljYXRp
b24vPC9zcGFuPjwvYT4pLCBub25lIG9mIHdoaWNoIGhhdmUgZXZlciBiZWVuIHJlcXVpcmVkIHRv
IHN1cHBvcnQgUEtDRS4mbmJzcDsgVGhlcmVmb3JlLCBtb3N0IGRvbuKAmXQuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw
MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UGVyIGZlZWRiYWNrIGFscmVhZHkgcHJvdmlk
ZWQsIEkgYmVsaWV2ZSB0aGF0IE9BdXRoIDIuMSBzaG91bGQgYWxpZ24gd2l0aCB0aGUgZ3VpZGFu
Y2UgYWxyZWFkeSBpbiB0aGUgZHJhZnQgU2VjdXJpdHkgQkNQLCByZXF1aXJpbmcgRUlUSEVSIHRo
ZSB1c2Ugb2YNCiBQS0NFIG9yIHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4mbmJzcDsgVHJ5aW5n
IHRvIHJldHJvYWN0aXZlbHkgaW1wb3NlIHVubmVjZXNzYXJ5IHJlcXVpcmVtZW50cyBvbiBleGlz
dGluZyBkZXBsb3ltZW50cyBpcyB1bmxpa2VseSB0byBzdWNjZWVkIGFuZCB3aWxsIHNpZ25pZmlj
YW50bHkgcmVkdWNlIHRoZSByZWxldmFuY2Ugb2YgdGhlIE9BdXRoIDIuMSBlZmZvcnQuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s
b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SW4gcGFydGljdWxhciwgYXV0aG9y
aXphdGlvbiBzZXJ2ZXJzIHNob3VsZG7igJl0IGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3
aGVuIHRoZXkgYWxyZWFkeSBzdXBwb3J0IHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4mbmJzcDsg
QW5kIGNsaWVudHMgc2hvdWxkbuKAmXQNCiByZWplY3QgcmVzcG9uc2VzIGZyb20gc2VydmVycyB0
aGF0IGRvbuKAmXQgc3VwcG9ydCBQS0NFIHdoZW4gdGhleSBkbyBjb250YWluIHRoZSBPcGVuSUQg
Q29ubmVjdCBub25jZS4mbmJzcDsgRG9pbmcgc28gd291bGQgdW5uZWNlc3NhcmlseSBicmVhayB0
aGluZ3MgYW5kIGNyZWF0ZSBjb25mdXNpb24gaW4gdGhlIG1hcmtldHBsYWNlLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0OzxhIGhyZWY9Im1h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNl
c0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRpY2sgSGFyZHQ8YnI+DQo8
Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgNiwgMjAyMCAxMDo0OCBBTTxicj4NCjxiPlRvOjwv
Yj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gT0F1dGggMi4xIC0g
cmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkhlbGxvITxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPldlIHdvdWxkIGxpa2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEg
Y29kZSBmbG93cy4gVGhpcyBpcyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5v
dCBjb21tb24gaW4gT3BlbklEIENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNv
bWUgb2YgdGhlIGlzc3Vlcw0KIHRoYXQgUEtDRSBwcm90ZWN0cyBhZ2FpbnN0LiBXZSB0aGluayB0
aGF0IG1vc3QgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBPQXV0
aCAyLjAsIGFuZCBoZW5jZSZuYnNwO2hhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcg
YmVzdCBwcmFjdGljZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5UaGUgYWR2YW50YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t
IGEgc2ltcGxlciBwcm9ncmFtbWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0aW9u
cyBhbmQgcHJvZmlsZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gcmVkdWNlZCBhdHRhY2sgc3Vy
ZmFjZSB3aGVuIHVzaW5nJm5ic3A7IFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZp
ZXIgaXMgc2VudCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQg
dmFsdWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPi0gZW5mb3JjZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0
byBoYW5kbGUgZm9yIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVj
ayBpcyBjb25kdWN0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPldoYXQgYXJlIGRpc2FkdmFudGFnZXMgYmVzaWRlcyB0aGUgcG90ZW50
aWFsIGltcGFjdCB0byBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cz8gSG93IHNpZ25pZmljYW50
IGlzIHRoYXQgaW1wYWN0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+RGljaywgQWFyb24sIGFuZCBUb3JzdGVuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9v
Z2FlLi5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNE
JmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5LWIy
ODQ3NDRiYzE3MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv
dDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp
ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy
Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA
aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMyMjIyMjIiPlZlbm5saWcgaGlsc2VuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAw
NTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+U3RlaW5hciBO
b2VtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPlBhcnRuZXIgVWRlbHQgQVM8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzIyMjIyMiI+U3lzdGVtdXR2aWtsZXI8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6IzIyMjIyMiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPnwmbmJzcDs8
YSBocmVmPSJtYWlsdG86c3RlaW5hckB1ZGVsdC5ubyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6I0ZGRkZDQyI+c3RlaW5hckB1ZGVsdC5ubzwv
c3Bhbj48L2E+Jm5ic3A7fCZuYnNwOzxhIGhyZWY9Im1haWx0bzpoZWlAdWRlbHQubm8iIHRhcmdl
dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQyI+aGVpQHVkZWx0Lm5vPC9zcGFu
PjwvYT4mbmJzcDsmbmJzcDt8Jm5ic3A7JiM0Mzs0Nw0KIDk1NSAyMSA2MjAmbmJzcDt8Jm5ic3A7
PGEgaHJlZj0iaHR0cDovL3d3dy51ZGVsdC5uby8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls
ZT0iY29sb3I6IzExNTVDQyI+d3d3LnVkZWx0Lm5vPC9zcGFuPjwvYT4mbmJzcDt8Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CH2PR00MB067920C5AE38FBC1A47E3CE1F5A40CH2PR00MB0679namp_--


From nobody Wed May  6 13:43:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F65F3A0B0E for ; Wed,  6 May 2020 13:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkYLzm3V-Jcz for ; Wed,  6 May 2020 13:43:10 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720243A0B0C for ; Wed,  6 May 2020 13:43:10 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id z2so1859624iol.11 for ; Wed, 06 May 2020 13:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U8pP5oD/IhTAtjUSeibnhlYQv32I1zQOCQ4jMxEYr6Y=; b=M/X42fTfcEnlRPO6xi8etv3D7TOUYEoh4+JfX71dByjfdQHNXOgT6W/zfHReNFM1G8 99oAqK3JxefK9PMwkdFDTK0jhLpQFLAFD6rDyfa+Xz5l7/ufVATIbDPT4k5jKkONwo/+ drhxzxqLmFN+d34cvc6U3W618aETlHqOWGrQU9kLDZVgEo19xfJL+TYwcyhKYgkp5yem 0MvCfU2wgFWYygAejqFe/tOgX1lBlSkLkpzFEpeZXCP0j5EI9mQL0YZw3qwhjHP6YvxI ENNpFGsXuC6y3eWiTnGrdPpWKAOhAAi25p54ReQCZ7x1DcDjttpv3IbjqLAOVUY695P0 C2Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U8pP5oD/IhTAtjUSeibnhlYQv32I1zQOCQ4jMxEYr6Y=; b=CSovtfqCZSSQg6nW7QZW8g4h8HSofVLM1Z8eAcA5vUXUUCmu7DPKoDJ2JYcCJhvmRj tJnnYzjJYUBjqmjfoUJt0lwVOdo1+q1s2l/NdTHvZcH0simhR9Pchz2YYrcPHH675Bic 2TI0Bboo6stV6kSaPFz1NkmotI4r+tXj11d80ylVPzeEechHoBGKOy8EG+AirDSVOWRN kacn6pLiDPiIxEimwEvXgqn1EZb9u3vp6oiz5xhzhSnZ+zAxI4j/AgnhXWA4iS5K7lxI 4MXqa4FCo9XGJXV/0woTFnM4ACRWvboLgcELj8hrholKmtKA4OvSnHx/AkY9KdOdAuWc rx3Q==
X-Gm-Message-State: AGi0PubDuTbD/e/yj6pnKJou8huPck2PNeASKVj05Gq1XA2/311GY5VV L4g32qfx1iXM7vl+9ABeINDVBX7OVyg=
X-Google-Smtp-Source: APiQypLa4JW2r16d6fB64wME/r3UYJWXIgduaA4mXfsprJha/sC0teqOPgktzBWdBvICFdXcVPB2kA==
X-Received: by 2002:a02:294a:: with SMTP id p71mr10504481jap.105.1588797788915;  Wed, 06 May 2020 13:43:08 -0700 (PDT)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com. [209.85.166.42]) by smtp.gmail.com with ESMTPSA id j4sm1576904ilq.5.2020.05.06.13.43.07 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 13:43:07 -0700 (PDT)
Received: by mail-io1-f42.google.com with SMTP id 19so306924ioz.10 for ; Wed, 06 May 2020 13:43:07 -0700 (PDT)
X-Received: by 2002:a6b:7302:: with SMTP id e2mr9466184ioh.98.1588797787334; Wed, 06 May 2020 13:43:07 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 6 May 2020 13:42:56 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Mike Jones 
Cc: Dick Hardt , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000bbf28605a500cf1a"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 20:43:14 -0000

--000000000000bbf28605a500cf1a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Going back to this point about server vs client requirements, since both
the Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE,
isn't that already imposing additional requirements on OpenID Connect
providers that don't currently exist in OpenID Connect alone?

OPs that want to be compliant with the Security BCP will need to add PKCE
support if they don't already have it (many of them already support it so
for many of them this will not be any change), so it seems like a very
small leap to also require clients implement PKCE as well.

On Wed, May 6, 2020 at 12:31 PM Mike Jones 
wrote:

> I realize what it says about servers.  My point is that OAuth 2.1=E2=80=
=99s
> requirements on *clients* should match those in the security BCP and not
> try to go beyond them.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Wednesday, May 6, 2020 12:24 PM
> *To:* Mike Jones 
> *Cc:* Dick Hardt ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Yes, the BCP says *clients* may use either PKCE or nonce to prevent
> authorization code injection. Shortly after that quoted segment is the
> below:
>
>
>
> > Authorization servers MUST support PKCE [RFC7636].
>
>
>
> On Wed, May 6, 2020 at 12:22 PM Mike Jones 
> wrote:
>
> Aaron, the section you cited at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2=
.1.1
> makes it clear that clients can support EITHER PKCE or the OpenID Connect
> nonce.   The text is:
>
>
>
>    Clients MUST prevent injection (replay) of authorization codes into
>
>    the authorization response by attackers.  The use of PKCE [RFC7636
> ]
>
>    is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
>
>    ID Token Claim [OpenID
> ]
> MAY be used as well.  The PKCE challenge or
>
>    OpenID Connect "nonce" MUST be transaction-specific and securely
>
>    bound to the client and the user agent in which the transaction was
>
>    started.
>
>
>
> We should not attempt to change that in OAuth 2.1, as doing so would
> needlessly break already working and secure clients.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Wednesday, May 6, 2020 11:56 AM
> *To:* Mike Jones 
> *Cc:* Dick Hardt ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> > In particular, authorization servers shouldn=E2=80=99t be required to s=
upport
> PKCE when they already support the OpenID Connect nonce.
>
>
>
> The Security BCP already requires that ASs support PKCE:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2=
.1.1 Are
> you suggesting that the Security BCP change that requirement as well? If
> so, that's a discussion that needs to be had ASAP. If not, then that's an
> implicit statement that it's okay for OpenID Connect implementations to n=
ot
> be best-practice OAuth implementations. And if that's the case, then I al=
so
> think it's acceptable that they are not complete OAuth 2.1 implementation=
s
> either.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 11:21 AM Mike Jones  40microsoft.com@dmarc.ietf.org> wrote:
>
> The disadvantage of requiring PKCE for OpenID Connect implementations is
> that you=E2=80=99re trying to add a normative requirement that=E2=80=99s =
not required of
> OpenID Connect deployments today, which would bifurcate the ecosystem.
> There are hundreds of implementations (including the 141 certified ones a=
t
> https://openid.net/certification/), none of which have ever been required
> to support PKCE.  Therefore, most don=E2=80=99t.
>
>
>
> Per feedback already provided, I believe that OAuth 2.1 should align with
> the guidance already in the draft Security BCP, requiring EITHER the use =
of
> PKCE or the OpenID Connect nonce.  Trying to retroactively impose
> unnecessary requirements on existing deployments is unlikely to succeed a=
nd
> will significantly reduce the relevance of the OAuth 2.1 effort.
>
>
>
> In particular, authorization servers shouldn=E2=80=99t be required to sup=
port PKCE
> when they already support the OpenID Connect nonce.  And clients shouldn=
=E2=80=99t
> reject responses from servers that don=E2=80=99t support PKCE when they d=
o contain
> the OpenID Connect nonce.  Doing so would unnecessarily break things and
> create confusion in the marketplace.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Dick Hardt
> *Sent:* Wednesday, May 6, 2020 10:48 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--000000000000bbf28605a500cf1a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Going back to this point about server vs client requiremen=
ts, since both the Security BCP and OAuth 2.1 currently say that ASs MUST s=
upport PKCE, isn't that already imposing additional requirements on Ope=
nID Connect providers that don't currently exist in OpenID Connect alon=
e?=C2=A0

OPs that want to be compliant with the Security=
 BCP will need to add PKCE support if they don't already have it (many =
of them already support it so for many of them this will not be any change)=
, so it seems like a very small leap to also require clients implement PKCE=
 as well.

On Wed, May 6, 2020 at 12:31 PM Mike Jones <Michael.Jones@microsoft.com> wrot=
e:











I realize what it=
 says about servers.=C2=A0 My point is that OAuth 2.1=E2=80=99s requirement=
s on
clients should match those in the security BCP and not try to go bey=
ond them.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com> 

Sent: Wednesday, May 6, 2020 12:24 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Dick Hardt <dick.hardt@gmail.com>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0




Yes, the BCP says *clients* may use either PKCE or n=
once to prevent authorization code injection. Shortly after that quoted seg=
ment is the below:




=C2=A0






=
>=C2=A0Authorization servers MUST support PKCE [RFC7636].<=
u>






=C2=A0






On Wed, May 6, 2020 at 12:22 PM Mike Jones <Michael.Jones@m=
icrosoft.com> wrote:










Aaron, the sectio=
n you cited at
https://tools.ietf.org/html/draft-i=
etf-oauth-security-topics-15#section-2.1.1 makes it clear that clients can support
 EITHER PKCE or the OpenID Connect nonce.=C2=A0=C2=A0 The text is:


=C2=A0<=
/u>


=C2=A0=C2=A0 Clients MUST prevent injection (rep=
lay) of authorization codes into


=C2=A0=C2=A0 the authorization response by attac=
kers.=C2=A0 The use of PKCE [RFC7636]


=C2=A0=C2=A0 is RECOMMENDED to this end.=C2=A0 T=
he OpenID Connect "nonce" parameter and


=C2=A0=C2=A0 ID Token Claim [OpenID]
 MAY be used as well.=C2=A0 The PKCE challenge or


=C2=A0=C2=A0 OpenID Connect "nonce" MU=
ST be transaction-specific and securely


=C2=A0=C2=A0 bound to the client and the user ag=
ent in which the transaction was


=C2=A0=C2=A0 started.


=C2=A0<=
/u>


We should not att=
empt to change that in OAuth 2.1, as doing so would needlessly break alread=
y working and secure clients.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com>


Sent: Wednesday, May 6, 2020 11:56 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Dick Hardt <dick.hardt@gmail.com>;
oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>




=C2=A0






> In particular, authorization servers shouldn=E2=
=80=99t be required to support PKCE when they already support the OpenID Co=
nnect nonce.






=C2=A0






The Security BCP already requires that ASs support P=
KCE:=C2=A0https://tools.ietf.org/html/draf=
t-ietf-oauth-security-topics-15#section-2.1.1=C2=A0Are
 you suggesting that the Security BCP change that requirement as well? If s=
o, that's a discussion that needs to be had ASAP. If not, then that'=
;s an implicit statement that it's okay for OpenID Connect implementati=
ons to not be best-practice OAuth implementations.
 And if that's the case, then I also think it's acceptable that the=
y are not complete OAuth 2.1 implementations either.






=C2=A0






=C2=A0




=C2=A0






=C2=A0




=C2=A0










=C2=A0






On Wed, May 6, 2020 at 11:21 AM Mike Jones <Micha=
el.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:










The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D
 Connect deployments today, which would bifurcate the ecosystem.=C2=A0 Ther=
e are hundreds of implementations (including the 141 certified ones at
https://openid.net/certificati=
on/), none of which have ever been required to support PKCE.=C2=
=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of
 PKCE or the OpenID Connect nonce.=C2=A0 Trying to retroactively impose unn=
ecessary requirements on existing deployments is unlikely to succeed and wi=
ll significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t
 reject responses from servers that don=E2=80=99t support PKCE when they do=
 contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessarily break=
 things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7








_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





















--000000000000bbf28605a500cf1a--


From nobody Wed May  6 13:48:55 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C435B3A0B28 for ; Wed,  6 May 2020 13:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6YOEckP-JcS for ; Wed,  6 May 2020 13:48:50 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF40C3A0B21 for ; Wed,  6 May 2020 13:48:49 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id j14so2533179lfg.9 for ; Wed, 06 May 2020 13:48:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FNt4DyonXPqToy21pcwiPzkHkbJtembyUGl/HOz6UK4=; b=puhzMaXs5Ho90iYhJSDLMJQObp//cXH+CHDFDkHlis/mHGHPpVN2Vn4hzDMrSQZsOo GNZYrQbpCz7uzFrmSDXuFM4IFhvsIJIYKlUKKeQM9cRLYOWlexHGNpNU0T63sBWYDQaz aZPNpeE0XQ3ExputgcrwI/Z0aDPsvlfB9NThKZcLYA17XEuBVnVw299+YFsItqh1I0dD //RobLYGL6EKYuppHp02S1iXgzQfcGXq8XA3esBJGIjdUzgC3/5iWeCcEtodsfeBeO5I gOUWraSQc45mbTtUPCecMdq20puwOExpZQQcYVvzbLOGo/GOApwUoaXbK4yOJ+XgKeR9 +MyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FNt4DyonXPqToy21pcwiPzkHkbJtembyUGl/HOz6UK4=; b=DUDGwELzsE0uLgkY1zKrKapXV/lUhQslBC542aUCt4KaIO/e+5ugmrbQBU9z6Qz7Ej Z0oG4rkcv4W/LX0f8zHBbHYsI6uGSinKQhMOPeB+WKpH9M1V4yPb/Dv0GgutEtezCCIS 8udgLpEjUuYObBIewXgiRQMsOcDsn71OmWfI1aQ8FitUOwUkW2a96zFsXdfpE00qlk5X LKqky5kpFZvF3x5tE/MaE1+T1yQmPZJQLfuBbKrYh9V5tZ4xWFETqfi7fX69Js77RlJD i/CABpMUJahegpDK2OmxUk8KUcBwxXMfVctKsDV6IJ2CGXSdr70ozdM6Dz/4FB4qB7Zk EFXA==
X-Gm-Message-State: AGi0PuaRSALGK77W1WdCM0MXOSlYM5ljNbvCjanF0WyzKiomn4RvFzYe D/36ZOxuzpSw9imeSnXKfoJlnuHGqieFDKWQNlU=
X-Google-Smtp-Source: APiQypKKZFnEu0uTm8MByBLxBeY8YynawrG62cY60SP2h7upJjUN+hWVVtVFwdAF1DuRHBegl2P2NLhmdvV3mcwWn1g=
X-Received: by 2002:a19:d:: with SMTP id 13mr6550896lfa.167.1588798127819; Wed, 06 May 2020 13:48:47 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 6 May 2020 13:48:21 -0700
Message-ID: 
To: Aaron Parecki 
Cc: Mike Jones , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000074ec405a500e4c5"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 20:48:53 -0000

--000000000000074ec405a500e4c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I hear Mike's point on breaking existing RPs. There are alot of them out
there.

For discussion purposes, let's call the current version OIDC 1.0 and the
version running OAuth 2.1, OIDC 1.1

Is there a reason a server can't be running both versions at the same time,
and support clients running both versions at the same time? The AS could
then enforce new and migrated clients running OIDC 1.1 to use PKCE.









=E1=90=A7

On Wed, May 6, 2020 at 1:43 PM Aaron Parecki  wrote:

> Going back to this point about server vs client requirements, since both
> the Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE,
> isn't that already imposing additional requirements on OpenID Connect
> providers that don't currently exist in OpenID Connect alone?
>
> OPs that want to be compliant with the Security BCP will need to add PKCE
> support if they don't already have it (many of them already support it so
> for many of them this will not be any change), so it seems like a very
> small leap to also require clients implement PKCE as well.
>
> On Wed, May 6, 2020 at 12:31 PM Mike Jones 
> wrote:
>
>> I realize what it says about servers.  My point is that OAuth 2.1=E2=80=
=99s
>> requirements on *clients* should match those in the security BCP and not
>> try to go beyond them.
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Aaron Parecki 
>> *Sent:* Wednesday, May 6, 2020 12:24 PM
>> *To:* Mike Jones 
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Yes, the BCP says *clients* may use either PKCE or nonce to prevent
>> authorization code injection. Shortly after that quoted segment is the
>> below:
>>
>>
>>
>> > Authorization servers MUST support PKCE [RFC7636].
>>
>>
>>
>> On Wed, May 6, 2020 at 12:22 PM Mike Jones 
>> wrote:
>>
>> Aaron, the section you cited at
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
2.1.1
>> makes it clear that clients can support EITHER PKCE or the OpenID Connec=
t
>> nonce.   The text is:
>>
>>
>>
>>    Clients MUST prevent injection (replay) of authorization codes into
>>
>>    the authorization response by attackers.  The use of PKCE [RFC7636
>> ]
>>
>>    is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
>>
>>    ID Token Claim [OpenID
>> ]
>> MAY be used as well.  The PKCE challenge or
>>
>>    OpenID Connect "nonce" MUST be transaction-specific and securely
>>
>>    bound to the client and the user agent in which the transaction was
>>
>>    started.
>>
>>
>>
>> We should not attempt to change that in OAuth 2.1, as doing so would
>> needlessly break already working and secure clients.
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Aaron Parecki 
>> *Sent:* Wednesday, May 6, 2020 11:56 AM
>> *To:* Mike Jones 
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> > In particular, authorization servers shouldn=E2=80=99t be required to =
support
>> PKCE when they already support the OpenID Connect nonce.
>>
>>
>>
>> The Security BCP already requires that ASs support PKCE:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
2.1.1 Are
>> you suggesting that the Security BCP change that requirement as well? If
>> so, that's a discussion that needs to be had ASAP. If not, then that's a=
n
>> implicit statement that it's okay for OpenID Connect implementations to =
not
>> be best-practice OAuth implementations. And if that's the case, then I a=
lso
>> think it's acceptable that they are not complete OAuth 2.1 implementatio=
ns
>> either.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote:
>>
>> The disadvantage of requiring PKCE for OpenID Connect implementations is
>> that you=E2=80=99re trying to add a normative requirement that=E2=80=99s=
 not required of
>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>> There are hundreds of implementations (including the 141 certified ones =
at
>> https://openid.net/certification/), none of which have ever been
>> required to support PKCE.  Therefore, most don=E2=80=99t.
>>
>>
>>
>> Per feedback already provided, I believe that OAuth 2.1 should align wit=
h
>> the guidance already in the draft Security BCP, requiring EITHER the use=
 of
>> PKCE or the OpenID Connect nonce.  Trying to retroactively impose
>> unnecessary requirements on existing deployments is unlikely to succeed =
and
>> will significantly reduce the relevance of the OAuth 2.1 effort.
>>
>>
>>
>> In particular, authorization servers shouldn=E2=80=99t be required to su=
pport
>> PKCE when they already support the OpenID Connect nonce.  And clients
>> shouldn=E2=80=99t reject responses from servers that don=E2=80=99t suppo=
rt PKCE when they
>> do contain the OpenID Connect nonce.  Doing so would unnecessarily break
>> things and create confusion in the marketplace.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Dick Hardt
>> *Sent:* Wednesday, May 6, 2020 10:48 AM
>> *To:* oauth@ietf.org
>> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Hello!
>>
>>
>>
>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>> best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as
>> the nonce solves some of the issues that PKCE protects against. We think
>> that most OpenID Connect implementations also support OAuth 2.0, and
>> hence have support for PKCE if following best practices.
>>
>>
>>
>> The advantages or requiring PKCE are:
>>
>>
>>
>> - a simpler programming model across all OAuth applications and profiles
>> as they all use PKCE
>>
>>
>>
>> - reduced attack surface when using  S256 as a fingerprint of the
>> verifier is sent through the browser instead of the clear text value
>>
>>
>>
>> - enforcement by AS not client - makes it easier to handle for client
>> developers and AS can ensure the check is conducted
>>
>>
>>
>> What are disadvantages besides the potential impact to OpenID Connect
>> deployments? How significant is that impact?
>>
>>
>>
>> Dick, Aaron, and Torsten
>>
>>
>>
>> =E1=90=A7
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>

--000000000000074ec405a500e4c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I hear Mike's point on breaking existing RPs. There ar=
e alot of them out there.

For discussion purposes, let&#=
39;s call the current version OIDC 1.0 and the version running OAuth 2.1, O=
IDC 1.1

Is there a reason a=C2=A0server can't =
be running both versions at the same time, and support clients running both=
 versions at the same time? The AS could then enforce new and migrated clie=
nts running OIDC 1.1 to use PKCE.


<=
br>




<=
br>

3D""=E1=90=A7

On Wed, May 6, 2020 =
at 1:43 PM Aaron Parecki <aaron@par=
ecki.com> wrote:
Going back to this point about server vs client re=
quirements, since both the Security BCP and OAuth 2.1 currently say that AS=
s MUST support PKCE, isn't that already imposing additional requirement=
s on OpenID Connect providers that don't currently exist in OpenID Conn=
ect alone?=C2=A0

OPs that want to be compliant with the =
Security BCP will need to add PKCE support if they don't already have i=
t (many of them already support it so for many of them this will not be any=
 change), so it seems like a very small leap to also require clients implem=
ent PKCE as well.

On Wed, May 6, 2020 at 12:31 PM Mike Jones <Michael.Jones@m=
icrosoft.com> wrote:











I realize what it=
 says about servers.=C2=A0 My point is that OAuth 2.1=E2=80=99s requirement=
s on
clients should match those in the security BCP and not try to go bey=
ond them.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com> 

Sent: Wednesday, May 6, 2020 12:24 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Dick Hardt <dick.hardt@gmail.com>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0




Yes, the BCP says *clients* may use either PKCE or n=
once to prevent authorization code injection. Shortly after that quoted seg=
ment is the below:




=C2=A0






=
>=C2=A0Authorization servers MUST support PKCE [RFC7636].<=
u>






=C2=A0






On Wed, May 6, 2020 at 12:22 PM Mike Jones <Michael.Jones@m=
icrosoft.com> wrote:










Aaron, the sectio=
n you cited at
https://tools.ietf.org/html/draft-i=
etf-oauth-security-topics-15#section-2.1.1 makes it clear that clients can support
 EITHER PKCE or the OpenID Connect nonce.=C2=A0=C2=A0 The text is:


=C2=A0<=
/u>


=C2=A0=C2=A0 Clients MUST prevent injection (rep=
lay) of authorization codes into


=C2=A0=C2=A0 the authorization response by attac=
kers.=C2=A0 The use of PKCE [RFC7636]


=C2=A0=C2=A0 is RECOMMENDED to this end.=C2=A0 T=
he OpenID Connect "nonce" parameter and


=C2=A0=C2=A0 ID Token Claim [OpenID]
 MAY be used as well.=C2=A0 The PKCE challenge or


=C2=A0=C2=A0 OpenID Connect "nonce" MU=
ST be transaction-specific and securely


=C2=A0=C2=A0 bound to the client and the user ag=
ent in which the transaction was


=C2=A0=C2=A0 started.


=C2=A0<=
/u>


We should not att=
empt to change that in OAuth 2.1, as doing so would needlessly break alread=
y working and secure clients.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com>


Sent: Wednesday, May 6, 2020 11:56 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Dick Hardt <dick.hardt@gmail.com>;
oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>




=C2=A0






> In particular, authorization servers shouldn=E2=
=80=99t be required to support PKCE when they already support the OpenID Co=
nnect nonce.






=C2=A0






The Security BCP already requires that ASs support P=
KCE:=C2=A0https://tools.ietf.org/html/draf=
t-ietf-oauth-security-topics-15#section-2.1.1=C2=A0Are
 you suggesting that the Security BCP change that requirement as well? If s=
o, that's a discussion that needs to be had ASAP. If not, then that'=
;s an implicit statement that it's okay for OpenID Connect implementati=
ons to not be best-practice OAuth implementations.
 And if that's the case, then I also think it's acceptable that the=
y are not complete OAuth 2.1 implementations either.






=C2=A0






=C2=A0




=C2=A0






=C2=A0




=C2=A0










=C2=A0






On Wed, May 6, 2020 at 11:21 AM Mike Jones <Micha=
el.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:










The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D
 Connect deployments today, which would bifurcate the ecosystem.=C2=A0 Ther=
e are hundreds of implementations (including the 141 certified ones at
https://openid.net/certificati=
on/), none of which have ever been required to support PKCE.=C2=
=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of
 PKCE or the OpenID Connect nonce.=C2=A0 Trying to retroactively impose unn=
ecessary requirements on existing deployments is unlikely to succeed and wi=
ll significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t
 reject responses from servers that don=E2=80=99t support PKCE when they do=
 contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessarily break=
 things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7<=
/p>







_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth























--000000000000074ec405a500e4c5--


From nobody Wed May  6 13:51:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833453A0A69 for ; Wed,  6 May 2020 13:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iAtTTvnMAvV for ; Wed,  6 May 2020 13:51:19 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640110.outbound.protection.outlook.com [40.107.64.110]) (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 E01C03A0B43 for ; Wed,  6 May 2020 13:51:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iqUGscLVG3fbSmU5FfQWHxiDrnlef90RqxPpdEQkUQPEnJabmm35/975Lqqd9rRfpsNQ8qFbMncbBvp8R9BnFhvJO0G8vUyMKvOcGk12/f0g2XwK5mA4ltvXUqA6nwDmMoKWuN0/6N5x0JDQk+/9yquE3HGXaXzvRHvvSrfIWXKS/GbML/W6NBn4rwvhHGXQPSHsnIjeJURHT7gYSzyRopcHVxIKOYWgZUyFbunJjwG4x0srMPa/w6INWlA8YIBYFOwkGVoq4T+DyBtirm9zmCItKeph8f9fyXugAgKOsQ2CD7bgASPlGIRGxSzI9mPgncwLBYMYM9r3u4xKLkJatA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cUFHV41rtwAZINGRXlUKSMoR5Ui2hlTfv1NmnN3EgQ8=; b=MX7o3SONs5+E80WIhgsso6yvAqGmY3GZvfzRzr8EfEfNQocS1h5HsQaEEX7uwlJzvX8o1lgZr2JheguOvu1WTnsm8k0PguCRnItWsaYb2vGXenGEJQ5/Da3vSbZGP4wY4chBCdUTTx8+5JDOP3+/WeelgclaauYIGfrBk6SmWkjuhpNuvc87nZZqZ/2oKmYcM7BRwBc8Pj7cDC6W2hgbQyF/DnkbSFlQ/5EyctIok5jBBlmT7MU+l11l4vjF4OHBhp5TC57XeLxWV4Oa0Q5oNj3Z+4W7Oa6wctsJBW2BqKn6RHIKe1txc1GOj0VW1Fau1lSpOR1TGckwWD2mkY3ycA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cUFHV41rtwAZINGRXlUKSMoR5Ui2hlTfv1NmnN3EgQ8=; b=XdTzGVzLFDSsn1lMsJkM328K7WXAF826DG7emkWOkeHz098ZSpLS6AEkZbSumjrLtrYYIlTADDhtsfQAUnS36sAHSxzjarezBSK3vDUh4y/bJ/as1FZvulnF2D2B0VR9Y6kGlDG7KVLgjl9oqzSp8Kh+tVKlQRi5lXOUW4ofupo=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0664.namprd00.prod.outlook.com (2603:10b6:610:ac::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3011.0; Wed, 6 May 2020 20:51:12 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8%9]) with mapi id 15.20.3015.000; Wed, 6 May 2020 20:51:12 +0000
From: Mike Jones 
To: Aaron Parecki 
CC: Dick Hardt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYj6BLITTZ1xD2qT2mwE3FiY+UuOA==
Date: Wed, 6 May 2020 20:51:12 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cb2c463d-21ed-40f7-84c9-000006a0ca7f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T20:46:47Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: fa8ef016-0558-4284-436e-08d7f1ff367b
x-ms-traffictypediagnostic: CH2PR00MB0664:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MwzDr9CXZJM6ZMpB1SAwOqsvCAXrCtxAsxYxHrlhK3tXO1uHrhBWSUpiBHPpLgnHdl4pDuapzuBdlAxONHfteJ9IjTpmJHIKo9JvTt2tFynhqhgvTHece+emKWdxxSRdBGbKCKwH8BvvWmnu59lv7rqg2nrMsBRY7Nnlf686y51nR0iaSz5aVGYOCXHz2XuvAogpB99q+vgfmUpX+nyVLlLTxp0yQQ75Oe+LUIQEmSYyZ/NLQXfAJJVd75UwF3h/0R4MBmNhvKb59sR//x5N1LBkQ4N43jp+YkGIQhGT/UqsDq5+Mm9ownrnpl4ILUWjfvr3MEsKap/jsHZ3cfZRR6RoZF9xr2XWmfDgTBHS5ipUgXL1Sn4k+cKVc8n0KU+jsKPbeEd1Ir03hfAW9lsLN/W14UjzT4qalmSIJTwEudYgRBgciyBVykVgTpYcd/YZj9tws8Li+5w9Uf7Bbv3tVgfNTjaC39OtrZEEwaPZMILTnbM4bDBqXTZXOmr5K4hFoZuYKnuLa5bqXRexD1ErJg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(136003)(346002)(366004)(39860400002)(376002)(33430700001)(82950400001)(82960400001)(4326008)(55016002)(966005)(66556008)(66446008)(8936002)(8990500004)(66476007)(64756008)(6916009)(33440700001)(86362001)(5660300002)(52536014)(33656002)(10290500003)(478600001)(8676002)(9686003)(76116006)(71200400001)(26005)(186003)(6506007)(7696005)(53546011)(66946007)(316002)(2906002)(54906003)(66574014)(166002)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: JlQ9W+sNogMM7gyaOm4OWqXHAAM/5/kIVOe4JqnoDVhJslaDV2XmHnKXJbLFQBnj1i6Mtcu5Odur1GOuTqS+ol3kqc69GyG7323fuCG8YCvOHpA//mEXIGMxTRpvPkAOKyXPd5gvYABgUN2aJx9VIoCUDNg/QlN9FyFT2oRnuXTJMGketo8CdIh9MtIN+hVMmeE3jyKa+JbV8yPvu+lmNHb18AdbCPIBzj8bNCmlwidbeAvDjjyHMbfJS1BsQMypL3m76dF31Yqxrhgm1WuiwH1oUbxKcWMyHZVJmfY1vANQtk8L6t4LL2ULg7AaSnYMwv0jwdclWiaXl3ht8twVr6nL3AoZ9iux9bChI34cvX4mu7l4Z9xS10JGsYkzm2+KLJTMsKpgxEYKWzxhtJ9z30/ijBl+7i9D3XxyR4fdi9QEHU0pKxR9lEDhgLf8Yhyry7ffLz9NeyGtuoYYQEYZ+BCuY5jbYUsqYuMy9gujKLwvaqwuVTig223LbkDn7CM0U+d3Mli0+4mfhgB/4lZWILcpdUT25uwNXCQlPEVz9XWZDu9w7PwFpsneZUxy4ebVzyLNmRFJ+Of1FbFq8u5f9jSLKWCRanGuXTs/JUHxEMv+elHyC9xMSCHUHlonZH646ijCAnLqtJFygJTIijigRe372xxUr7X5enPt7la1sRLp3KisHQ9CQ4b6YawCiPGP9Rt9JRSdpVFF2QegqpKGu2J5cvtxwUoDp5HhiSusNte28v0OhuHfNs0NLiHXRf7lOr17olHKbFsaBB5AcwwL8JPqpqkqupWMMNG4LfywxhY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679EC6188095591526B518FF5A40CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa8ef016-0558-4284-436e-08d7f1ff367b
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 20:51:12.7633 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RjGbPhLyC4r+sYj8aGDunV8MzjXpijVcOj1O/d/bc4g6US9NGg3owTRayTPB78RFaTn5+aDscawI+0K/anaB5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0664
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 20:51:23 -0000

--_000_CH2PR00MB0679EC6188095591526B518FF5A40CH2PR00MB0679namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmVxdWlyaW5nIGEgY2hhbmdlIHRvIGV2ZXJ5IGRlcGxveWVkIFJQIGlzIG5vdCDigJxhIHZlcnkg
c21hbGwgbGVhcOKAnS4gIEl04oCZcyBhbiBpbnZhc2l2ZSBiaWcgZGVhbCwgaW50cm9kdWNpbmcg
YSBicmVha2luZyBjaGFuZ2UgYW5kIGJpZnVyY2F0aW5nIGEgd2VsbC1mdW5jdGlvbmluZyBlY29z
eXN0ZW0gd2l0aG91dCBzdWZmaWNpZW50IGNhdXNlLg0KDQpXaGF0IHRoaXMgYWN0dWFsbHkgcG9p
bnRzIG91dCB0byBtZSBpcyB0aGF0IHdlIHNob3VsZCBtb2RpZnkgdGhlIGxhbmd1YWdlIGluIHRo
ZSBTZWN1cml0eSBCQ1AgdG8gc2F5IHNvbWV0aGluZyBsaWtlIOKAnE9BdXRoIFNlcnZlcnMgTVVT
VCBzdXBwb3J0IFBLQ0UgdW5sZXNzIHRoZXkgYXJlIG9ubHkgdXNlZCBmb3IgT3BlbklEIENvbm5l
Y3QgQXV0aGVudGljYXRpb24gUmVxdWVzdHPigJ0uICBJ4oCZZCB0aG91Z2h0IHRoYXQgdGhhdCB3
YXMgYWxyZWFkeSB0aGUgY2FzZSwgYXMgdGhhdCBtaXJyb3JzIHRoZSBjbGllbnQgcmVxdWlyZW1l
bnRzIGFuZCBJIGFwcGFyZW50bHkgZmFpbGVkIHRvIHJlYWQgaXQgY2xvc2VseSBlbm91Z2guICBJ
4oCZbGwgc3VibWl0IGEgc2VwYXJhdGUgcmVxdWVzdCBmb3IgdGhlIGNoYW5nZSB0byB0aGUgU2Vj
dXJpdHkgQkNQIHRvIG1ha2UgaXQgc2VsZi1jb25zaXN0ZW50Lg0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBB
YXJvbiBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDYs
IDIwMjAgMTo0MyBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bT4NCkNjOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT47IG9hdXRoQGlldGYub3Jn
DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/DQoNCkdv
aW5nIGJhY2sgdG8gdGhpcyBwb2ludCBhYm91dCBzZXJ2ZXIgdnMgY2xpZW50IHJlcXVpcmVtZW50
cywgc2luY2UgYm90aCB0aGUgU2VjdXJpdHkgQkNQIGFuZCBPQXV0aCAyLjEgY3VycmVudGx5IHNh
eSB0aGF0IEFTcyBNVVNUIHN1cHBvcnQgUEtDRSwgaXNuJ3QgdGhhdCBhbHJlYWR5IGltcG9zaW5n
IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9uIE9wZW5JRCBDb25uZWN0IHByb3ZpZGVycyB0aGF0
IGRvbid0IGN1cnJlbnRseSBleGlzdCBpbiBPcGVuSUQgQ29ubmVjdCBhbG9uZT8NCg0KT1BzIHRo
YXQgd2FudCB0byBiZSBjb21wbGlhbnQgd2l0aCB0aGUgU2VjdXJpdHkgQkNQIHdpbGwgbmVlZCB0
byBhZGQgUEtDRSBzdXBwb3J0IGlmIHRoZXkgZG9uJ3QgYWxyZWFkeSBoYXZlIGl0IChtYW55IG9m
IHRoZW0gYWxyZWFkeSBzdXBwb3J0IGl0IHNvIGZvciBtYW55IG9mIHRoZW0gdGhpcyB3aWxsIG5v
dCBiZSBhbnkgY2hhbmdlKSwgc28gaXQgc2VlbXMgbGlrZSBhIHZlcnkgc21hbGwgbGVhcCB0byBh
bHNvIHJlcXVpcmUgY2xpZW50cyBpbXBsZW1lbnQgUEtDRSBhcyB3ZWxsLg0KDQpPbiBXZWQsIE1h
eSA2LCAyMDIwIGF0IDEyOjMxIFBNIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJIHJlYWxp
emUgd2hhdCBpdCBzYXlzIGFib3V0IHNlcnZlcnMuICBNeSBwb2ludCBpcyB0aGF0IE9BdXRoIDIu
MeKAmXMgcmVxdWlyZW1lbnRzIG9uIGNsaWVudHMgc2hvdWxkIG1hdGNoIHRob3NlIGluIHRoZSBz
ZWN1cml0eSBCQ1AgYW5kIG5vdCB0cnkgdG8gZ28gYmV5b25kIHRoZW0uDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy
b206IEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tp
LmNvbT4+DQpTZW50OiBXZWRuZXNkYXksIE1heSA2LCAyMDIwIDEyOjI0IFBNDQpUbzogTWlrZSBK
b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20+Pg0KQ2M6IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0
bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/
DQoNClllcywgdGhlIEJDUCBzYXlzICpjbGllbnRzKiBtYXkgdXNlIGVpdGhlciBQS0NFIG9yIG5v
bmNlIHRvIHByZXZlbnQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbi4gU2hvcnRseSBhZnRl
ciB0aGF0IHF1b3RlZCBzZWdtZW50IGlzIHRoZSBiZWxvdzoNCg0KPiBBdXRob3JpemF0aW9uIHNl
cnZlcnMgTVVTVCBzdXBwb3J0IFBLQ0UgW1JGQzc2MzZdLg0KDQpPbiBXZWQsIE1heSA2LCAyMDIw
IGF0IDEyOjIyIFBNIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls
dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBYXJvbiwgdGhlIHNlY3Rp
b24geW91IGNpdGVkIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h
dXRoLXNlY3VyaXR5LXRvcGljcy0xNSNzZWN0aW9uLTIuMS4xIG1ha2VzIGl0IGNsZWFyIHRoYXQg
Y2xpZW50cyBjYW4gc3VwcG9ydCBFSVRIRVIgUEtDRSBvciB0aGUgT3BlbklEIENvbm5lY3Qgbm9u
Y2UuICAgVGhlIHRleHQgaXM6DQoNCiAgIENsaWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlvbiAo
cmVwbGF5KSBvZiBhdXRob3JpemF0aW9uIGNvZGVzIGludG8NCiAgIHRoZSBhdXRob3JpemF0aW9u
IHJlc3BvbnNlIGJ5IGF0dGFja2Vycy4gIFRoZSB1c2Ugb2YgUEtDRSBbUkZDNzYzNjxodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzYzNj5dDQogICBpcyBSRUNPTU1FTkRFRCB0byB0aGlz
IGVuZC4gIFRoZSBPcGVuSUQgQ29ubmVjdCAibm9uY2UiIHBhcmFtZXRlciBhbmQNCiAgIElEIFRv
a2VuIENsYWltIFtPcGVuSUQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
b2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3JlZi1PcGVuSUQ+XSBNQVkgYmUgdXNlZCBhcyB3ZWxs
LiAgVGhlIFBLQ0UgY2hhbGxlbmdlIG9yDQogICBPcGVuSUQgQ29ubmVjdCAibm9uY2UiIE1VU1Qg
YmUgdHJhbnNhY3Rpb24tc3BlY2lmaWMgYW5kIHNlY3VyZWx5DQogICBib3VuZCB0byB0aGUgY2xp
ZW50IGFuZCB0aGUgdXNlciBhZ2VudCBpbiB3aGljaCB0aGUgdHJhbnNhY3Rpb24gd2FzDQogICBz
dGFydGVkLg0KDQpXZSBzaG91bGQgbm90IGF0dGVtcHQgdG8gY2hhbmdlIHRoYXQgaW4gT0F1dGgg
Mi4xLCBhcyBkb2luZyBzbyB3b3VsZCBuZWVkbGVzc2x5IGJyZWFrIGFscmVhZHkgd29ya2luZyBh
bmQgc2VjdXJlIGNsaWVudHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEFhcm9uIFBhcmVja2kgPGFhcm9u
QHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+DQpTZW50OiBXZWRuZXNkYXks
IE1heSA2LCAyMDIwIDExOjU2IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IERpY2sg
SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+
OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJO
QUxdIFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KPiBJbiBwYXJ0
aWN1bGFyLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkbuKAmXQgYmUgcmVxdWlyZWQgdG8g
c3VwcG9ydCBQS0NFIHdoZW4gdGhleSBhbHJlYWR5IHN1cHBvcnQgdGhlIE9wZW5JRCBDb25uZWN0
IG5vbmNlLg0KDQpUaGUgU2VjdXJpdHkgQkNQIGFscmVhZHkgcmVxdWlyZXMgdGhhdCBBU3Mgc3Vw
cG9ydCBQS0NFOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1z
ZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMSBBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB0
aGUgU2VjdXJpdHkgQkNQIGNoYW5nZSB0aGF0IHJlcXVpcmVtZW50IGFzIHdlbGw/IElmIHNvLCB0
aGF0J3MgYSBkaXNjdXNzaW9uIHRoYXQgbmVlZHMgdG8gYmUgaGFkIEFTQVAuIElmIG5vdCwgdGhl
biB0aGF0J3MgYW4gaW1wbGljaXQgc3RhdGVtZW50IHRoYXQgaXQncyBva2F5IGZvciBPcGVuSUQg
Q29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgdG8gbm90IGJlIGJlc3QtcHJhY3RpY2UgT0F1dGggaW1w
bGVtZW50YXRpb25zLiBBbmQgaWYgdGhhdCdzIHRoZSBjYXNlLCB0aGVuIEkgYWxzbyB0aGluayBp
dCdzIGFjY2VwdGFibGUgdGhhdCB0aGV5IGFyZSBub3QgY29tcGxldGUgT0F1dGggMi4xIGltcGxl
bWVudGF0aW9ucyBlaXRoZXIuDQoNCg0KDQoNCg0KDQpPbiBXZWQsIE1heSA2LCAyMDIwIGF0IDEx
OjIxIEFNIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll
dGYub3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNClRo
ZSBkaXNhZHZhbnRhZ2Ugb2YgcmVxdWlyaW5nIFBLQ0UgZm9yIE9wZW5JRCBDb25uZWN0IGltcGxl
bWVudGF0aW9ucyBpcyB0aGF0IHlvdeKAmXJlIHRyeWluZyB0byBhZGQgYSBub3JtYXRpdmUgcmVx
dWlyZW1lbnQgdGhhdOKAmXMgbm90IHJlcXVpcmVkIG9mIE9wZW5JRCBDb25uZWN0IGRlcGxveW1l
bnRzIHRvZGF5LCB3aGljaCB3b3VsZCBiaWZ1cmNhdGUgdGhlIGVjb3N5c3RlbS4gIFRoZXJlIGFy
ZSBodW5kcmVkcyBvZiBpbXBsZW1lbnRhdGlvbnMgKGluY2x1ZGluZyB0aGUgMTQxIGNlcnRpZmll
ZCBvbmVzIGF0IGh0dHBzOi8vb3BlbmlkLm5ldC9jZXJ0aWZpY2F0aW9uLyksIG5vbmUgb2Ygd2hp
Y2ggaGF2ZSBldmVyIGJlZW4gcmVxdWlyZWQgdG8gc3VwcG9ydCBQS0NFLiAgVGhlcmVmb3JlLCBt
b3N0IGRvbuKAmXQuDQoNClBlciBmZWVkYmFjayBhbHJlYWR5IHByb3ZpZGVkLCBJIGJlbGlldmUg
dGhhdCBPQXV0aCAyLjEgc2hvdWxkIGFsaWduIHdpdGggdGhlIGd1aWRhbmNlIGFscmVhZHkgaW4g
dGhlIGRyYWZ0IFNlY3VyaXR5IEJDUCwgcmVxdWlyaW5nIEVJVEhFUiB0aGUgdXNlIG9mIFBLQ0Ug
b3IgdGhlIE9wZW5JRCBDb25uZWN0IG5vbmNlLiAgVHJ5aW5nIHRvIHJldHJvYWN0aXZlbHkgaW1w
b3NlIHVubmVjZXNzYXJ5IHJlcXVpcmVtZW50cyBvbiBleGlzdGluZyBkZXBsb3ltZW50cyBpcyB1
bmxpa2VseSB0byBzdWNjZWVkIGFuZCB3aWxsIHNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSByZWxl
dmFuY2Ugb2YgdGhlIE9BdXRoIDIuMSBlZmZvcnQuDQoNCkluIHBhcnRpY3VsYXIsIGF1dGhvcml6
YXRpb24gc2VydmVycyBzaG91bGRu4oCZdCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IFBLQ0Ugd2hl
biB0aGV5IGFscmVhZHkgc3VwcG9ydCB0aGUgT3BlbklEIENvbm5lY3Qgbm9uY2UuICBBbmQgY2xp
ZW50cyBzaG91bGRu4oCZdCByZWplY3QgcmVzcG9uc2VzIGZyb20gc2VydmVycyB0aGF0IGRvbuKA
mXQgc3VwcG9ydCBQS0NFIHdoZW4gdGhleSBkbyBjb250YWluIHRoZSBPcGVuSUQgQ29ubmVjdCBu
b25jZS4gIERvaW5nIHNvIHdvdWxkIHVubmVjZXNzYXJpbHkgYnJlYWsgdGhpbmdzIGFuZCBjcmVh
dGUgY29uZnVzaW9uIGluIHRoZSBtYXJrZXRwbGFjZS4NCg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1
dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+
PiBPbiBCZWhhbGYgT2YgRGljayBIYXJkdA0KU2VudDogV2VkbmVzZGF5LCBNYXkgNiwgMjAyMCAx
MDo0OCBBTQ0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1Ympl
Y3Q6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPw0KDQpIZWxsbyENCg0KV2Ug
d291bGQgbGlrZSB0byBoYXZlIFBLQ0UgYmUgYSBNVVNUIGluIE9BdXRoIDIuMSBjb2RlIGZsb3dz
LiBUaGlzIGlzIGJlc3QgcHJhY3RpY2UgZm9yIE9BdXRoIDIuMC4gSXQgaXMgbm90IGNvbW1vbiBp
biBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIGFzIHRoZSBub25jZSBzb2x2ZXMgc29tZSBvZiB0aGUg
aXNzdWVzIHRoYXQgUEtDRSBwcm90ZWN0cyBhZ2FpbnN0LiBXZSB0aGluayB0aGF0IG1vc3QgT3Bl
bklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBo
ZW5jZSBoYXZlIHN1cHBvcnQgZm9yIFBLQ0UgaWYgZm9sbG93aW5nIGJlc3QgcHJhY3RpY2VzLg0K
DQpUaGUgYWR2YW50YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6DQoNCi0gYSBzaW1wbGVyIHBy
b2dyYW1taW5nIG1vZGVsIGFjcm9zcyBhbGwgT0F1dGggYXBwbGljYXRpb25zIGFuZCBwcm9maWxl
cyBhcyB0aGV5IGFsbCB1c2UgUEtDRQ0KDQotIHJlZHVjZWQgYXR0YWNrIHN1cmZhY2Ugd2hlbiB1
c2luZyAgUzI1NiBhcyBhIGZpbmdlcnByaW50IG9mIHRoZSB2ZXJpZmllciBpcyBzZW50IHRocm91
Z2ggdGhlIGJyb3dzZXIgaW5zdGVhZCBvZiB0aGUgY2xlYXIgdGV4dCB2YWx1ZQ0KDQotIGVuZm9y
Y2VtZW50IGJ5IEFTIG5vdCBjbGllbnQgLSBtYWtlcyBpdCBlYXNpZXIgdG8gaGFuZGxlIGZvciBj
bGllbnQgZGV2ZWxvcGVycyBhbmQgQVMgY2FuIGVuc3VyZSB0aGUgY2hlY2sgaXMgY29uZHVjdGVk
DQoNCldoYXQgYXJlIGRpc2FkdmFudGFnZXMgYmVzaWRlcyB0aGUgcG90ZW50aWFsIGltcGFjdCB0
byBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cz8gSG93IHNpZ25pZmljYW50IGlzIHRoYXQgaW1w
YWN0Pw0KDQpEaWNrLCBBYXJvbiwgYW5kIFRvcnN0ZW4NCg0KW2h0dHBzOi8vbWFpbGZvb2dhZS4u
YXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBl
PXplcm9jb250ZW50Jmd1aWQ9NDUyNDM4YmEtZDQyOS00NjU2LWFjZTktYjI4NDc0NGJjMTcxXeGQ
pw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo
IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_CH2PR00MB0679EC6188095591526B518FF5A40CH2PR00MB0679namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
UmVxdWlyaW5nIGEgY2hhbmdlIHRvIGV2ZXJ5IGRlcGxveWVkIFJQIGlzIG5vdCDigJxhIHZlcnkg
c21hbGwgbGVhcOKAnS4mbmJzcDsgSXTigJlzIGFuIGludmFzaXZlIGJpZyBkZWFsLCBpbnRyb2R1
Y2luZyBhIGJyZWFraW5nIGNoYW5nZSBhbmQgYmlmdXJjYXRpbmcgYSB3ZWxsLWZ1bmN0aW9uaW5n
IGVjb3N5c3RlbSB3aXRob3V0IHN1ZmZpY2llbnQgY2F1c2UuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojMDAyMDYwIj5XaGF0IHRoaXMgYWN0dWFsbHkgcG9pbnRzIG91dCB0byBtZSBpcyB0
aGF0IHdlIHNob3VsZCBtb2RpZnkgdGhlIGxhbmd1YWdlIGluIHRoZSBTZWN1cml0eSBCQ1AgdG8g
c2F5IHNvbWV0aGluZyBsaWtlIOKAnE9BdXRoIFNlcnZlcnMgTVVTVCBzdXBwb3J0IFBLQ0UgdW5s
ZXNzIHRoZXkgYXJlIG9ubHkgdXNlZCBmb3IgT3BlbklEIENvbm5lY3QgQXV0aGVudGljYXRpb24N
CiBSZXF1ZXN0c+KAnS4mbmJzcDsgSeKAmWQgdGhvdWdodCB0aGF0IHRoYXQgd2FzIGFscmVhZHkg
dGhlIGNhc2UsIGFzIHRoYXQgbWlycm9ycyB0aGUgY2xpZW50IHJlcXVpcmVtZW50cyBhbmQgSSBh
cHBhcmVudGx5IGZhaWxlZCB0byByZWFkIGl0IGNsb3NlbHkgZW5vdWdoLiZuYnNwOyBJ4oCZbGwg
c3VibWl0IGEgc2VwYXJhdGUgcmVxdWVzdCBmb3IgdGhlIGNoYW5nZSB0byB0aGUgU2VjdXJpdHkg
QkNQIHRvIG1ha2UgaXQgc2VsZi1jb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p
a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFhcm9u
IFBhcmVja2kgJmx0O2Fhcm9uQHBhcmVja2kuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk
bmVzZGF5LCBNYXkgNiwgMjAyMCAxOjQzIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZs
dDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBEaWNrIEhh
cmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT88bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29pbmcgYmFjayB0byB0aGlzIHBv
aW50IGFib3V0IHNlcnZlciB2cyBjbGllbnQgcmVxdWlyZW1lbnRzLCBzaW5jZSBib3RoIHRoZSBT
ZWN1cml0eSBCQ1AgYW5kIE9BdXRoIDIuMSBjdXJyZW50bHkgc2F5IHRoYXQgQVNzIE1VU1Qgc3Vw
cG9ydCBQS0NFLCBpc24ndCB0aGF0IGFscmVhZHkgaW1wb3NpbmcgYWRkaXRpb25hbCByZXF1aXJl
bWVudHMgb24gT3BlbklEIENvbm5lY3QgcHJvdmlkZXJzIHRoYXQgZG9uJ3QNCiBjdXJyZW50bHkg
ZXhpc3QgaW4gT3BlbklEIENvbm5lY3QgYWxvbmU/Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PUHMgdGhhdCB3YW50IHRvIGJlIGNvbXBsaWFudCB3
aXRoIHRoZSBTZWN1cml0eSBCQ1Agd2lsbCBuZWVkIHRvIGFkZCBQS0NFIHN1cHBvcnQgaWYgdGhl
eSBkb24ndCBhbHJlYWR5IGhhdmUgaXQgKG1hbnkgb2YgdGhlbSBhbHJlYWR5IHN1cHBvcnQgaXQg
c28gZm9yIG1hbnkgb2YgdGhlbSB0aGlzIHdpbGwgbm90IGJlIGFueSBjaGFuZ2UpLCBzbyBpdCBz
ZWVtcyBsaWtlIGEgdmVyeSBzbWFsbCBsZWFwIHRvIGFsc28NCiByZXF1aXJlIGNsaWVudHMgaW1w
bGVtZW50IFBLQ0UgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMjozMSBQTSBNaWtlIEpv
bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNo
YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSByZWFsaXplIHdoYXQgaXQgc2F5cyBhYm91dCBz
ZXJ2ZXJzLiZuYnNwOyBNeSBwb2ludCBpcyB0aGF0IE9BdXRoIDIuMeKAmXMgcmVxdWlyZW1lbnRz
IG9uDQo8Yj5jbGllbnRzPC9iPiBzaG91bGQgbWF0Y2ggdGhvc2UgaW4gdGhlIHNlY3VyaXR5IEJD
UCBhbmQgbm90IHRyeSB0byBnbyBiZXlvbmQgdGhlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
LS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8
L2I+IEFhcm9uIFBhcmVja2kgJmx0OzxhIGhyZWY9Im1haWx0bzphYXJvbkBwYXJlY2tpLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPmFhcm9uQHBhcmVja2kuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6
PC9iPiBXZWRuZXNkYXksIE1heSA2LCAyMDIwIDEyOjI0IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtl
IEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0
YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8
Yj5DYzo8L2I+IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWls
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs7DQo8YSBo
cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9y
ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVx
dWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVz
LCB0aGUgQkNQIHNheXMgKmNsaWVudHMqIG1heSB1c2UgZWl0aGVyIFBLQ0Ugb3Igbm9uY2UgdG8g
cHJldmVudCBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uLiBTaG9ydGx5IGFmdGVyIHRoYXQg
cXVvdGVkIHNlZ21lbnQgaXMgdGhlIGJlbG93OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwO0F1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIHN1cHBv
cnQgUEtDRSBbUkZDNzYzNl0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMjoyMiBQ
TSBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BYXJvbiwgdGhlIHNlY3Rpb24geW91IGNp
dGVkIGF0DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24tMi4xLjEiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0
eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMTwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
IG1ha2VzIGl0IGNsZWFyIHRoYXQgY2xpZW50cyBjYW4gc3VwcG9ydA0KIEVJVEhFUiBQS0NFIG9y
IHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4mbmJzcDsmbmJzcDsgVGhlIHRleHQgaXM6PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s
b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IENsaWVudHMgTVVTVCBw
cmV2ZW50IGluamVjdGlvbiAocmVwbGF5KSBvZiBhdXRob3JpemF0aW9uIGNvZGVzIGludG88L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y
OmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgYnkgYXR0YWNr
ZXJzLiZuYnNwOyBUaGUgdXNlIG9mIFBLQ0UgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9yZmM3NjM2IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O1Byb29mIEtleSBm
b3IgQ29kZSBFeGNoYW5nZSBieSBPQXV0aCBQdWJsaWMgQ2xpZW50cyZxdW90OyI+UkZDNzYzNjwv
YT5dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlzIFJFQ09NTUVOREVEIHRvIHRoaXMgZW5kLiZu
YnNwOyBUaGUgT3BlbklEIENvbm5lY3QgJnF1b3Q7bm9uY2UmcXVvdDsgcGFyYW1ldGVyIGFuZDwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBJRCBUb2tlbiBDbGFpbSBbPGEgaHJlZj0iaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3Jl
Zi1PcGVuSUQiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7T3BlbklEIENvbm5lY3QgQ29y
ZSAxLjAgaW5jb3Jwb3JhdGluZyBlcnJhdGEgc2V0IDEmcXVvdDsiPk9wZW5JRDwvYT5dDQogTUFZ
IGJlIHVzZWQgYXMgd2VsbC4mbmJzcDsgVGhlIFBLQ0UgY2hhbGxlbmdlIG9yPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+
Jm5ic3A7Jm5ic3A7IE9wZW5JRCBDb25uZWN0ICZxdW90O25vbmNlJnF1b3Q7IE1VU1QgYmUgdHJh
bnNhY3Rpb24tc3BlY2lmaWMgYW5kIHNlY3VyZWx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGJv
dW5kIHRvIHRoZSBjbGllbnQgYW5kIHRoZSB1c2VyIGFnZW50IGluIHdoaWNoIHRoZSB0cmFuc2Fj
dGlvbiB3YXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc3RhcnRlZC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5XZSBzaG91bGQgbm90IGF0dGVtcHQgdG8gY2hhbmdl
IHRoYXQgaW4gT0F1dGggMi4xLCBhcyBkb2luZyBzbyB3b3VsZCBuZWVkbGVzc2x5IGJyZWFrIGFs
cmVhZHkgd29ya2luZyBhbmQgc2VjdXJlIGNsaWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206
PC9iPiBBYXJvbiBQYXJlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20i
IHRhcmdldD0iX2JsYW5rIj5hYXJvbkBwYXJlY2tpLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50
OjwvYj4gV2VkbmVzZGF5LCBNYXkgNiwgMjAyMCAxMTo1NiBBTTxicj4NCjxiPlRvOjwvYj4gTWlr
ZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0K
PGI+Q2M6PC9iPiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFp
bC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KPGEg
aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5v
cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gT0F1
dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZndDsgSW4gcGFydGljdWxhciwgYXV0aG9yaXphdGlvbiBzZXJ2ZXJz
IHNob3VsZG7igJl0IGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgYWxyZWFk
eSBzdXBwb3J0IHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBTZWN1cml0eSBCQ1AgYWxy
ZWFkeSByZXF1aXJlcyB0aGF0IEFTcyBzdXBwb3J0IFBLQ0U6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1
I3NlY3Rpb24tMi4xLjEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMTwvYT4m
bmJzcDtBcmUNCiB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBTZWN1cml0eSBCQ1AgY2hhbmdlIHRo
YXQgcmVxdWlyZW1lbnQgYXMgd2VsbD8gSWYgc28sIHRoYXQncyBhIGRpc2N1c3Npb24gdGhhdCBu
ZWVkcyB0byBiZSBoYWQgQVNBUC4gSWYgbm90LCB0aGVuIHRoYXQncyBhbiBpbXBsaWNpdCBzdGF0
ZW1lbnQgdGhhdCBpdCdzIG9rYXkgZm9yIE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyB0
byBub3QgYmUgYmVzdC1wcmFjdGljZSBPQXV0aCBpbXBsZW1lbnRhdGlvbnMuDQogQW5kIGlmIHRo
YXQncyB0aGUgY2FzZSwgdGhlbiBJIGFsc28gdGhpbmsgaXQncyBhY2NlcHRhYmxlIHRoYXQgdGhl
eSBhcmUgbm90IGNvbXBsZXRlIE9BdXRoIDIuMSBpbXBsZW1lbnRhdGlvbnMgZWl0aGVyLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5PbiBXZWQsIE1heSA2LCAyMDIwIGF0IDExOjIxIEFNIE1pa2UgSm9u
ZXMgJmx0O01pY2hhZWwuSm9uZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y
ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlIGRpc2FkdmFudGFn
ZSBvZiByZXF1aXJpbmcgUEtDRSBmb3IgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGlz
IHRoYXQgeW914oCZcmUgdHJ5aW5nIHRvIGFkZCBhIG5vcm1hdGl2ZSByZXF1aXJlbWVudCB0aGF0
4oCZcyBub3QgcmVxdWlyZWQgb2YgT3BlbklEDQogQ29ubmVjdCBkZXBsb3ltZW50cyB0b2RheSwg
d2hpY2ggd291bGQgYmlmdXJjYXRlIHRoZSBlY29zeXN0ZW0uJm5ic3A7IFRoZXJlIGFyZSBodW5k
cmVkcyBvZiBpbXBsZW1lbnRhdGlvbnMgKGluY2x1ZGluZyB0aGUgMTQxIGNlcnRpZmllZCBvbmVz
IGF0DQo8YSBocmVmPSJodHRwczovL29wZW5pZC5uZXQvY2VydGlmaWNhdGlvbi8iIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MDt0ZXh0LWRlY29yYXRpb246bm9uZSI+
aHR0cHM6Ly9vcGVuaWQubmV0L2NlcnRpZmljYXRpb24vPC9zcGFuPjwvYT4pLCBub25lIG9mIHdo
aWNoIGhhdmUgZXZlciBiZWVuIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRS4mbmJzcDsgVGhlcmVm
b3JlLCBtb3N0IGRvbuKAmXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2
MCI+UGVyIGZlZWRiYWNrIGFscmVhZHkgcHJvdmlkZWQsIEkgYmVsaWV2ZSB0aGF0IE9BdXRoIDIu
MSBzaG91bGQgYWxpZ24gd2l0aCB0aGUgZ3VpZGFuY2UgYWxyZWFkeSBpbiB0aGUgZHJhZnQgU2Vj
dXJpdHkgQkNQLCByZXF1aXJpbmcgRUlUSEVSIHRoZSB1c2Ugb2YNCiBQS0NFIG9yIHRoZSBPcGVu
SUQgQ29ubmVjdCBub25jZS4mbmJzcDsgVHJ5aW5nIHRvIHJldHJvYWN0aXZlbHkgaW1wb3NlIHVu
bmVjZXNzYXJ5IHJlcXVpcmVtZW50cyBvbiBleGlzdGluZyBkZXBsb3ltZW50cyBpcyB1bmxpa2Vs
eSB0byBzdWNjZWVkIGFuZCB3aWxsIHNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSByZWxldmFuY2Ug
b2YgdGhlIE9BdXRoIDIuMSBlZmZvcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6
IzAwMjA2MCI+SW4gcGFydGljdWxhciwgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZG7igJl0
IGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgUEtDRSB3aGVuIHRoZXkgYWxyZWFkeSBzdXBwb3J0IHRo
ZSBPcGVuSUQgQ29ubmVjdCBub25jZS4mbmJzcDsgQW5kIGNsaWVudHMgc2hvdWxkbuKAmXQNCiBy
ZWplY3QgcmVzcG9uc2VzIGZyb20gc2VydmVycyB0aGF0IGRvbuKAmXQgc3VwcG9ydCBQS0NFIHdo
ZW4gdGhleSBkbyBjb250YWluIHRoZSBPcGVuSUQgQ29ubmVjdCBub25jZS4mbmJzcDsgRG9pbmcg
c28gd291bGQgdW5uZWNlc3NhcmlseSBicmVhayB0aGluZ3MgYW5kIGNyZWF0ZSBjb25mdXNpb24g
aW4gdGhlIG1hcmtldHBsYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw
NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5G
cm9tOjwvYj4gT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBC
ZWhhbGYgT2YgPC9iPkRpY2sgSGFyZHQ8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkg
NiwgMjAyMCAxMDo0OCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbGxvITxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIHdvdWxkIGxpa2UgdG8gaGF2
ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29kZSBmbG93cy4gVGhpcyBpcyBiZXN0IHBy
YWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBjb21tb24gaW4gT3BlbklEIENvbm5lY3Qg
c2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUgb2YgdGhlIGlzc3Vlcw0KIHRoYXQgUEtD
RSBwcm90ZWN0cyBhZ2FpbnN0LiBXZSB0aGluayB0aGF0IG1vc3QgT3BlbklEIENvbm5lY3QgaW1w
bGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBoZW5jZSZuYnNwO2hhdmUg
c3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgYWR2YW50
YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIGEgc2ltcGxlciBwcm9ncmFtbWluZyBtb2Rl
bCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0aW9ucyBhbmQgcHJvZmlsZXMgYXMgdGhleSBhbGwg
dXNlIFBLQ0U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPi0gcmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3aGVuIHVzaW5nJm5ic3A7IFMyNTYg
YXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZpZXIgaXMgc2VudCB0aHJvdWdoIHRoZSBicm93
c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQgdmFsdWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gZW5mb3JjZW1lbnQgYnkgQVMg
bm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUgZm9yIGNsaWVudCBkZXZlbG9w
ZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25kdWN0ZWQ8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQgYXJlIGRp
c2FkdmFudGFnZXMgYmVzaWRlcyB0aGUgcG90ZW50aWFsIGltcGFjdCB0byBPcGVuSUQgQ29ubmVj
dCBkZXBsb3ltZW50cz8gSG93IHNpZ25pZmljYW50IGlzIHRoYXQgaW1wYWN0PzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGljaywgQWFy
b24sIGFuZCBUb3JzdGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAw
MDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLi5hcHBzcG90LmNvbS90P3NlbmRlcj1h
WkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtn
dWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5LWIyODQ3NDRiYzE3MSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9
Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CH2PR00MB0679EC6188095591526B518FF5A40CH2PR00MB0679namp_--


From nobody Wed May  6 14:03:32 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9996E3A0B04 for ; Wed,  6 May 2020 14:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnITsXxdCLjq for ; Wed,  6 May 2020 14:03:26 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626D63A09FC for ; Wed,  6 May 2020 14:03:26 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id z22so2593982lfd.0 for ; Wed, 06 May 2020 14:03:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WT1zhQodIJIpzlJRxq5w+DvTT/29gufOvNbzVX1xJuo=; b=CkabtBxTsLduKokOQKQlhbdFXwIvY1HvlT/W5+HjC7sWNNK7GnFcTgRXVg6vIVQFPX yNEhzXZNOrhBvGwKEIl2gkmvk9yy3ZkrmTnRvXiZ+gfdxsgO7PjruJqMNcOtKk+tcetp Kzl3t0gJ56xlFeUNqMYuhg8M4vMuCv/MdnXqnDugfsoQ+UoYOzmJuY9lMJCUP8aSFNMc yUhWciqV+i3EtjE7SA9ArCu5ZOY57t7qbm9iVlBFbdfSxzSLV+dCNLzyAkymaFqkI+1E mfHwHvWqXFKXtnLzqbz0iVzdgOnou1/27DmO/T6cf0LQbKwWk6cOMdHRGHwjI2sxVAen nN6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WT1zhQodIJIpzlJRxq5w+DvTT/29gufOvNbzVX1xJuo=; b=bLUM0np9OcSu45p2PJSqlaxT38aVaHd2as24iM4KrmB/wPgusoErpaMTYnCzWzBc5G gITnXOp2+aa6uac9aj/kKQ9C7M/izOkCvNMHUfNWzFToAGMmfy9JLgqmV4oTGgbU9Glv lHM+sGaP3+x8/CNGFrghgZfOz/MAOJhwGOG3YWqTewnFK7vTircv4yrtol5c0EcgOwVK yQk9+flCk229CYTTtnmLFQnVy3nEtLtgZ7j62V7BFIe88VrUTwX+8q9JsjQwmG85kuBZ 7d1rZYgps4xso74Ro+6xuD0v5LwYHlXKNba3/RqIgCdbXqOTcaFQZxWZYAAV1HbHgNXO qwew==
X-Gm-Message-State: AGi0PuZbJKVvNlnFH0mN1CQ0i7WH47XvYoOxDyLJLqzizEqhJkzCVRh1 8L9k4nOeL8LSHKiMP1rYQCUdYLSrpJp1RjNtvUCp9kMXxsxya1UEDh43nE4pUOc1XDZUgpEP/ei OiIhbwlaDesjiUw==
X-Google-Smtp-Source: APiQypLDoLEko7xCJq1b2OcvpdXEus7R4LZ9nGEgo9JJ4PujnAPB5TYgnpW32/k+f9pwB1w4+OR0e6JEz5KPVHHpK48=
X-Received: by 2002:ac2:57cd:: with SMTP id k13mr5795838lfo.104.1588799004188;  Wed, 06 May 2020 14:03:24 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Wed, 6 May 2020 15:02:57 -0600
Message-ID: 
To: Aaron Parecki 
Cc: Mike Jones , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000043e32e05a50118d5"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 21:03:31 -0000

--00000000000043e32e05a50118d5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think the point is that the Security BCP in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1=
.1
requires that the authz request has either the PKCE "code_challenge" or the
OIDC "nonce". Whereas 2.1 in
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.1.3
flat out requires PKCE "code_challenge" in the authz request. They are not
equivalent and have very different ramifications on interoperability etc..


On Wed, May 6, 2020 at 2:43 PM Aaron Parecki  wrote:

> Going back to this point about server vs client requirements, since both
> the Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE,
> isn't that already imposing additional requirements on OpenID Connect
> providers that don't currently exist in OpenID Connect alone?
>
> OPs that want to be compliant with the Security BCP will need to add PKCE
> support if they don't already have it (many of them already support it so
> for many of them this will not be any change), so it seems like a very
> small leap to also require clients implement PKCE as well.
>
> On Wed, May 6, 2020 at 12:31 PM Mike Jones 
> wrote:
>
>> I realize what it says about servers.  My point is that OAuth 2.1=E2=80=
=99s
>> requirements on *clients* should match those in the security BCP and not
>> try to go beyond them.
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Aaron Parecki 
>> *Sent:* Wednesday, May 6, 2020 12:24 PM
>> *To:* Mike Jones 
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Yes, the BCP says *clients* may use either PKCE or nonce to prevent
>> authorization code injection. Shortly after that quoted segment is the
>> below:
>>
>>
>>
>> > Authorization servers MUST support PKCE [RFC7636].
>>
>>
>>
>> On Wed, May 6, 2020 at 12:22 PM Mike Jones 
>> wrote:
>>
>> Aaron, the section you cited at
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
2.1.1
>> makes it clear that clients can support EITHER PKCE or the OpenID Connec=
t
>> nonce.   The text is:
>>
>>
>>
>>    Clients MUST prevent injection (replay) of authorization codes into
>>
>>    the authorization response by attackers.  The use of PKCE [RFC7636
>> ]
>>
>>    is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
>>
>>    ID Token Claim [OpenID
>> ]
>> MAY be used as well.  The PKCE challenge or
>>
>>    OpenID Connect "nonce" MUST be transaction-specific and securely
>>
>>    bound to the client and the user agent in which the transaction was
>>
>>    started.
>>
>>
>>
>> We should not attempt to change that in OAuth 2.1, as doing so would
>> needlessly break already working and secure clients.
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Aaron Parecki 
>> *Sent:* Wednesday, May 6, 2020 11:56 AM
>> *To:* Mike Jones 
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> > In particular, authorization servers shouldn=E2=80=99t be required to =
support
>> PKCE when they already support the OpenID Connect nonce.
>>
>>
>>
>> The Security BCP already requires that ASs support PKCE:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
2.1.1 Are
>> you suggesting that the Security BCP change that requirement as well? If
>> so, that's a discussion that needs to be had ASAP. If not, then that's a=
n
>> implicit statement that it's okay for OpenID Connect implementations to =
not
>> be best-practice OAuth implementations. And if that's the case, then I a=
lso
>> think it's acceptable that they are not complete OAuth 2.1 implementatio=
ns
>> either.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote:
>>
>> The disadvantage of requiring PKCE for OpenID Connect implementations is
>> that you=E2=80=99re trying to add a normative requirement that=E2=80=99s=
 not required of
>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>> There are hundreds of implementations (including the 141 certified ones =
at
>> https://openid.net/certification/), none of which have ever been
>> required to support PKCE.  Therefore, most don=E2=80=99t.
>>
>>
>>
>> Per feedback already provided, I believe that OAuth 2.1 should align wit=
h
>> the guidance already in the draft Security BCP, requiring EITHER the use=
 of
>> PKCE or the OpenID Connect nonce.  Trying to retroactively impose
>> unnecessary requirements on existing deployments is unlikely to succeed =
and
>> will significantly reduce the relevance of the OAuth 2.1 effort.
>>
>>
>>
>> In particular, authorization servers shouldn=E2=80=99t be required to su=
pport
>> PKCE when they already support the OpenID Connect nonce.  And clients
>> shouldn=E2=80=99t reject responses from servers that don=E2=80=99t suppo=
rt PKCE when they
>> do contain the OpenID Connect nonce.  Doing so would unnecessarily break
>> things and create confusion in the marketplace.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Dick Hardt
>> *Sent:* Wednesday, May 6, 2020 10:48 AM
>> *To:* oauth@ietf.org
>> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Hello!
>>
>>
>>
>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>> best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as
>> the nonce solves some of the issues that PKCE protects against. We think
>> that most OpenID Connect implementations also support OAuth 2.0, and
>> hence have support for PKCE if following best practices.
>>
>>
>>
>> The advantages or requiring PKCE are:
>>
>>
>>
>> - a simpler programming model across all OAuth applications and profiles
>> as they all use PKCE
>>
>>
>>
>> - reduced attack surface when using  S256 as a fingerprint of the
>> verifier is sent through the browser instead of the clear text value
>>
>>
>>
>> - enforcement by AS not client - makes it easier to handle for client
>> developers and AS can ensure the check is conducted
>>
>>
>>
>> What are disadvantages besides the potential impact to OpenID Connect
>> deployments? How significant is that impact?
>>
>>
>>
>> Dick, Aaron, and Torsten
>>
>>
>>
>> =E1=90=A7
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

--00000000000043e32e05a50118d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think the point is that the Security BCP in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#sec=
tion-2.1.1 requires that the authz request has either the PKCE "co=
de_challenge" or the OIDC "nonce". Whereas 2.1 in h=
ttps://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.1.3 =
flat out requires PKCE "code_challenge" in the authz request. The=
y are not equivalent and have very different ramifications on interoperabil=
ity etc.. 


On Wed, May 6, 2020 at 2:43 P=
M Aaron Parecki <aaron@parecki.com<=
/a>> wrote:
<=
div dir=3D"ltr">Going back to this point about server vs client requirement=
s, since both the Security BCP and OAuth 2.1 currently say that ASs MUST su=
pport PKCE, isn't that already imposing additional requirements on Open=
ID Connect providers that don't currently exist in OpenID Connect alone=
?=C2=A0

OPs that want to be compliant with the Security =
BCP will need to add PKCE support if they don't already have it (many o=
f them already support it so for many of them this will not be any change),=
 so it seems like a very small leap to also require clients implement PKCE =
as well.

On Wed, May 6, 2020 at 12:31 PM Mike Jones <Michael.Jones@microsof=
t.com> wrote:











I realize what it=
 says about servers.=C2=A0 My point is that OAuth 2.1=E2=80=99s requirement=
s on
clients should match those in the security BCP and not try to go bey=
ond them.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com> 

Sent: Wednesday, May 6, 2020 12:24 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Dick Hardt <dick.hardt@gmail.com>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0




Yes, the BCP says *clients* may use either PKCE or n=
once to prevent authorization code injection. Shortly after that quoted seg=
ment is the below:




=C2=A0






=
>=C2=A0Authorization servers MUST support PKCE [RFC7636].<=
u>






=C2=A0






On Wed, May 6, 2020 at 12:22 PM Mike Jones <Michael.Jones@m=
icrosoft.com> wrote:










Aaron, the sectio=
n you cited at
https://tools.ietf.org/html/draft-i=
etf-oauth-security-topics-15#section-2.1.1 makes it clear that clients can support
 EITHER PKCE or the OpenID Connect nonce.=C2=A0=C2=A0 The text is:


=C2=A0<=
/u>


=C2=A0=C2=A0 Clients MUST prevent injection (rep=
lay) of authorization codes into


=C2=A0=C2=A0 the authorization response by attac=
kers.=C2=A0 The use of PKCE [RFC7636]


=C2=A0=C2=A0 is RECOMMENDED to this end.=C2=A0 T=
he OpenID Connect "nonce" parameter and


=C2=A0=C2=A0 ID Token Claim [OpenID]
 MAY be used as well.=C2=A0 The PKCE challenge or


=C2=A0=C2=A0 OpenID Connect "nonce" MU=
ST be transaction-specific and securely


=C2=A0=C2=A0 bound to the client and the user ag=
ent in which the transaction was


=C2=A0=C2=A0 started.


=C2=A0<=
/u>


We should not att=
empt to change that in OAuth 2.1, as doing so would needlessly break alread=
y working and secure clients.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com>


Sent: Wednesday, May 6, 2020 11:56 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Dick Hardt <dick.hardt@gmail.com>;
oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>




=C2=A0






> In particular, authorization servers shouldn=E2=
=80=99t be required to support PKCE when they already support the OpenID Co=
nnect nonce.






=C2=A0






The Security BCP already requires that ASs support P=
KCE:=C2=A0https://tools.ietf.org/html/draf=
t-ietf-oauth-security-topics-15#section-2.1.1=C2=A0Are
 you suggesting that the Security BCP change that requirement as well? If s=
o, that's a discussion that needs to be had ASAP. If not, then that'=
;s an implicit statement that it's okay for OpenID Connect implementati=
ons to not be best-practice OAuth implementations.
 And if that's the case, then I also think it's acceptable that the=
y are not complete OAuth 2.1 implementations either.






=C2=A0






=C2=A0




=C2=A0






=C2=A0




=C2=A0










=C2=A0






On Wed, May 6, 2020 at 11:21 AM Mike Jones <Micha=
el.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:










The disadvantage =
of requiring PKCE for OpenID Connect implementations is that you=E2=80=99re=
 trying to add a normative requirement that=E2=80=99s not required of OpenI=
D
 Connect deployments today, which would bifurcate the ecosystem.=C2=A0 Ther=
e are hundreds of implementations (including the 141 certified ones at
https://openid.net/certificati=
on/), none of which have ever been required to support PKCE.=C2=
=A0 Therefore, most don=E2=80=99t.


=C2=A0<=
/u>


Per feedback alre=
ady provided, I believe that OAuth 2.1 should align with the guidance alrea=
dy in the draft Security BCP, requiring EITHER the use of
 PKCE or the OpenID Connect nonce.=C2=A0 Trying to retroactively impose unn=
ecessary requirements on existing deployments is unlikely to succeed and wi=
ll significantly reduce the relevance of the OAuth 2.1 effort.


=C2=A0<=
/u>


In particular, au=
thorization servers shouldn=E2=80=99t be required to support PKCE when they=
 already support the OpenID Connect nonce.=C2=A0 And clients shouldn=E2=80=
=99t
 reject responses from servers that don=E2=80=99t support PKCE when they do=
 contain the OpenID Connect nonce.=C2=A0 Doing so would unnecessarily break=
 things and create confusion in the marketplace.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dick Hardt

Sent: Wednesday, May 6, 2020 10:48 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7<=
/p>







_______________________________________________

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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000043e32e05a50118d5--


From nobody Wed May  6 14:04:07 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADC33A09E7 for ; Wed,  6 May 2020 14:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Level: 
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuIoHcLnj-1F for ; Wed,  6 May 2020 14:04:03 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640132.outbound.protection.outlook.com [40.107.64.132]) (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 EC3493A09E8 for ; Wed,  6 May 2020 14:04:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cWoa3TKMUFT9S4Meff/lIOahFSkbLJlWWYSzE6fUP4m9J8rfEgnd1G4DUVqkwxtvmSZ4UeZGAbu16nv7i/0y2IYKI/nZI7ZZrxuKDvn7GfyT+9MR21p6gA05HK8y70lNoHWGUOxlbsiBHSdF77w+J2B2OvcAbgCy0KSw91+qJXoH4Xp2h9WnAs9bSJVN5TgaUB1HuK5Tn9KWXORkeMdeQyiEPWDsmHz9pYBikpO1gzhyCTIbmgZkemjjossNfw6TUDbRo6B8Ej2CdGHCAy1LoA7CAMwYP9yYCuX289b2jxL2QFPPj3jZw5HJ5B4P1eerpV+Bowa1Z8RBejKPo9wGWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRnVJvsyM6ZWSysDKrEP7FSU6iBj30zwPHCBGhTkMSY=; b=isbm6ZmA2Bu0bbMSBrk80D9h0UbLMnU0RckZLwEgHNoxZYMw7nNMcDAPIMI5ICP08IPEvF/eDn5M5P/wZH30KcY81gr34AhThgyuQJAnacnfLOvkOxxtxnpegvwXXxYxR0I7OQMmwbGB4Ux7QHu9T7bsx3MMHj2rxbABUw6M0/1eqROm7BSZiLqwFhvY3inUoqqAhYH2SAo/sipie6ktL+vJdEPu8lXkiEH8j1SX7wu2gm5BrIu68qxctsuHPZEQaQKxSQxkUWORpISj+kVbgxU158FMTJ5gN/PvTUxJuv+8WrtqvBOHeI1TiuG1Tj66aKbS2UxG+/u6RzLBWjVeuQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRnVJvsyM6ZWSysDKrEP7FSU6iBj30zwPHCBGhTkMSY=; b=Xqxk6UlEQ1jBTo2RLe3vgSn8qj3hie/wqe/nWN03fNzo9qd/mcxM7LtffdudsJi97rzTKJMLHb3s0E7NIqfhXlOCpWDxk6xjCnNMbqaIKNe9zYbb4aZ/AOEOkqlVspyS/ftqzhrwEBBVhu7SXs+ANfbf+fJe5sz5/ifatHZ0yVg=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0680.namprd00.prod.outlook.com (2603:10b6:610:7b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3017.0; Wed, 6 May 2020 21:04:01 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::c8f1:c1e0:dcd6:53b8%9]) with mapi id 15.20.3015.000; Wed, 6 May 2020 21:04:01 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: Aligning PKCE requirements within the OAuth Security BCP
Thread-Index: AdYj6LQIxySgSLU1QSGU5Eu1xd7HJQ==
Date: Wed, 6 May 2020 21:04:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=60a9a76f-fa90-4614-961b-0000b48f653a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T20:55:01Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e059d67d-debb-42a0-9ce8-08d7f2010080
x-ms-traffictypediagnostic: CH2PR00MB0680:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8XsbKbsb1yYCmgqyLj3uL0ObshEDggkcGiOaF//c0eNzpygnB+bkdifaFeyv6jvzgVZB5JwX7l9tlU/Txqha2ghSMAHt7blZARl3VaxJ/A32R2QnWb1OyyELyvKf12LebEtgyqwzBFSn+bx/LCmVGX2YSkHgWaHcCv+rtlY03l9pTTwcn6mxFTzlEwBEPu3rDuYQrNsE62Sza1JvmqE+6HOA4OD3LXFljHbVKHHfJdqorGrDO3NAtO+9qhJ8uQybKDNsK72ELGj3ZFK6d7AXxb0jOWsrUxLU8Tg4Rv5ITXuivExe6o7F+9BpXYUDxYEburY4pZgE3OiNjv1EMyVWfOUqzqNpBhOaBNiVKBiV++9ipQ1nO/GcE98SQtI4iXYX9dP5Rnj6e44nSXxUCiUD6JYrNgWAmpm6WoHUwBYNQXAEowFWC86LZqM/qLpcnW0TXp3++I8FaJEZ9Fsu0ltlRnR6oLw52IdCl5rtDFAE+I0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(346002)(39860400002)(376002)(366004)(396003)(33430700001)(478600001)(186003)(9686003)(55016002)(7696005)(26005)(71200400001)(2906002)(8936002)(15650500001)(86362001)(33656002)(52536014)(6506007)(166002)(8676002)(10290500003)(966005)(316002)(82950400001)(8990500004)(6916009)(33440700001)(76116006)(82960400001)(66556008)(66476007)(5660300002)(66946007)(66446008)(64756008); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: nKpvjESmVMMxuEPeRWj01t34vAXO9BJowQPhQprJXerWBUO53c/PuBRgmse+VZ3PjdZTY4OimGBR2W1pmg3Xodpz6Wy7PBf4g9z0U9qn+M6F1EnTIEtCcSzrLupsv3S7Pz/aAYezGc+ZIseWURBep9n7HYKiKthKrfv8jtU/m2cfvcI/5y/S8Lr/1Skar0us8rwfwUS+gDhxNvexF+QYwS06AnT0pA8wge7OT26JS0ldq1TZRf4ZQt+PIij3rQbWHed6M2Q4HK4HVCdZZ8e4MahFXoaqhK3Om/o/Fuo28O1xxZakEWndbcGdIDrVkNoJbcjlhTm39LGWq84Z3HvUNXf5ZwY4da4L4bSscpeNiGsihjlUCNKsb6cYSeaskJmoIda9zuG0/EkI9ZYATSujC4UZZFGIBcc80CdHlOTnmV8aEjPoN8jF9r60Elk/2aOBUiNk4XDOHeqTi/spL8uPrWnaLYi0ej50B/EWT8POgXwGM4uhR74k9mInUR42PNPviF8V+Y0Bg8/QfwQgcdVue1UyIZNBdEyTr9kuDWMG0Qtddpy5BHah7FjTFifgzsorQkOBjJTXR0zRV9FPMMruFS79bCqaUjw0pwBMpmDXD7EJfc1ZP0VgPJzEapivwTg3Ok6GVn4z4DGAplnBiJVnTSk07unJc6LR3tdF7T+ar8IxPMM9+PM3Efk+v7EnX++k8+3Rswjah7dl7X8xMRR3c13QclSpkQ6y5LSKqY790nw+ph8MFmWtKGIYWwDkZ0NLF54vRfFIZE5uR2wwh3wmZffs7dVyu7CpbXmDhuPiT+s=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB06795B5A025D45DC02234C42F5A40CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e059d67d-debb-42a0-9ce8-08d7f2010080
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 21:04:01.2576 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9Ta06i7wgQTFd+uU2eb4zY50IH7lZH91quHqt4/NwIo7V6i6ei8GmC7f+A6L2fEfU/2DBsOwXRByIMUX+yjECQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0680
Archived-At: 
Subject: [OAUTH-WG] Aligning PKCE requirements within the OAuth Security BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 21:04:06 -0000

--_000_CH2PR00MB06795B5A025D45DC02234C42F5A40CH2PR00MB0679namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As is being discussed in the thread "[OAUTH-WG] OAuth 2.1 - require PKCE?",=
 https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.=
1.1 has inconsistent requirements for PKCE support between clients and serv=
ers.  Per the first paragraph, clients must either use PKCE or use the Open=
ID Connect nonce to prevent authorization code injection.  Whereas the four=
th paragraph says "Authorization servers MUST support PKCE [RFC7636].".  Th=
is imposes a requirement on servers that isn't present for corresponding cl=
ients.  (I missed this internal discrepancy within the specification when I=
 did my review.)

I therefore request that the fourth paragraph by change to read: "OAuth Ser=
vers MUST support PKCE [RFC7636] unless they are only used for OpenID Conne=
ct Authentication Requests", making the requirements on clients and servers=
 parallel.  That way PKCE will still be there unless you don't need it.  (A=
nd it still could be there if the server implementer chooses to have it in =
all cases, but that should be their call.)

                                                       Thank you,
                                                       -- Mike


--_000_CH2PR00MB06795B5A025D45DC02234C42F5A40CH2PR00MB0679namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











As is being discussed in the thread “[OAUTH-WG=
] OAuth 2.1 - require PKCE?”,

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1=
.1 has inconsistent requirements for PKCE support between clients and s=
ervers.  Per the first paragraph, clients must either use PKCE or use =
the OpenID Connect nonce to prevent authorization
 code injection.  Whereas the fourth paragraph says “Authoriz=
ation servers MUST support PKCE [RFC7636].”.  This imposes a=
 requirement on servers that isn’t present for corresponding clients.=
  (I missed this internal discrepancy within the specification
 when I did my review.)


 


I therefore request that the fourth paragraph by cha=
nge to read:
“OAuth Servers MUST support PKCE [RF=
C7636] unless they are only used for OpenID Connect Authentication Requests=
”, making the requirements on clients and servers parallel. =
 That way PKCE will still be there unless you don’t
 need it.  (And it still could be there if the server implementer choo=
ses to have it in all cases, but that should be their call.)


 


   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p; Thank you,


   &nbs=
p;             =
            &nb=
sp;            =
             --=
 Mike


 






--_000_CH2PR00MB06795B5A025D45DC02234C42F5A40CH2PR00MB0679namp_--


From nobody Wed May  6 14:38:10 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F221F3A0437 for ; Wed,  6 May 2020 14:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSDLRwfNkegx for ; Wed,  6 May 2020 14:38:07 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8663A0366 for ; Wed,  6 May 2020 14:38:07 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id v4so5921699wme.1 for ; Wed, 06 May 2020 14:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C3inm/Yz6h/0qd+/Rw8tlbQY0upF4tQe8GjAZcIVCYQ=; b=BBmashBp+S2Z3COe83tO4HSPs88fWTDYOpfzuyxIumCE0LZHXWv+pFPfUINdN+3Mkj aOPXxWpPDN992WXYiM+MKtSKG4A8b4WLi526QvAWDV4ViVlReHJjsot2yfl2GBwjsrdI 7gITG3EMGd+oXnw/PLGyFRSupE2SJcTfCaWpaHB7QedK2ItOQOU1a4z4wlP7r8DM7x9i tJ2OUwcXCQw7BlEvnIhl/iAICIV0EoMKfV4Zelg/zrG8n9PvaOHbYZOjx562pwjiwIbD xJsuc40sCVySethxDrO9qVKeoAUj58xzChK0XgJNqFUlCUYHX9wyJxmzTFH/nWJZGBc3 cMDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C3inm/Yz6h/0qd+/Rw8tlbQY0upF4tQe8GjAZcIVCYQ=; b=E/gtQIDOVf1jSkegH1UDMMqN+DXGjQZpHLJgLN4XDqhgninr0WReFNoGeOdS4+xbta 2bSHI12UPlZDSW62sds87aew0uq1VGOvw7+eawQTTTEnbX3KdHLNYWoGeTH2fsmWXRGf 8eGpiABkztJlHdTz3EfK7rK9SBqIu4HXl8Yi7rLQnnbXuGEbpBXqjHB1VPq9YrEjvgmI jbAU0sbMDCcBgYM7c7GXBYW+2VE3GummBe79YRqh3+vWLfJYzc7EWFuUWL/weJ5QpstE r84sLQcts88NCzFqu72u+MZhAXbgM2hVpRiOHtid73TgPFgYuUaOifj7l7MlorrUsJlA 7ECw==
X-Gm-Message-State: AGi0PubNlHjYCOrZojipZYl06M17TdrMVTZQnwRhpWKtskgY2Na0DMKd M6Cz4wsgN83AwoK58RGqyDslcm+RqT3A0HXmb1jubV2n
X-Google-Smtp-Source: APiQypKnQYleKd4+JJdmziqei0L1GpgUZTm3ngr7WXoIb+Do+futT+q/k03Vk6x5Rm4t7lIfNq3p6hNRxDwS6unBs0Q=
X-Received: by 2002:a1c:808c:: with SMTP id b134mr6895924wmd.131.1588801085620;  Wed, 06 May 2020 14:38:05 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Sascha Preibisch 
Date: Wed, 6 May 2020 14:37:22 -0700
Message-ID: 
To: Mike Jones 
Cc: "oauth@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Aligning PKCE requirements within the OAuth Security BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 May 2020 21:38:09 -0000

The document is called "...Best Current Practice ..." and includes
recommendations. Could it be sufficient to say "Authorization servers
support PKCE" in section 2.1.1?  I believe MUST and other such terms
may not necessarily belong into such document.

Regards,
Sascha

On Wed, 6 May 2020 at 14:04, Mike Jones
 wrote:
>
> As is being discussed in the thread =E2=80=9C[OAUTH-WG] OAuth 2.1 - requi=
re PKCE?=E2=80=9D, https://tools.ietf.org/html/draft-ietf-oauth-security-to=
pics-15#section-2.1..1 has inconsistent requirements for PKCE support betwe=
en clients and servers.  Per the first paragraph, clients must either use P=
KCE or use the OpenID Connect nonce to prevent authorization code injection=
.  Whereas the fourth paragraph says =E2=80=9CAuthorization servers MUST su=
pport PKCE [RFC7636].=E2=80=9D.  This imposes a requirement on servers that=
 isn=E2=80=99t present for corresponding clients.  (I missed this internal =
discrepancy within the specification when I did my review.)
>
>
>
> I therefore request that the fourth paragraph by change to read: =E2=80=
=9COAuth Servers MUST support PKCE [RFC7636] unless they are only used for =
OpenID Connect Authentication Requests=E2=80=9D, making the requirements on=
 clients and servers parallel.  That way PKCE will still be there unless yo=
u don=E2=80=99t need it.  (And it still could be there if the server implem=
enter chooses to have it in all cases, but that should be their call.)
>
>
>
>                                                        Thank you,
>
>                                                        -- Mike
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu May  7 01:23:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9ED3A0A4D for ; Thu,  7 May 2020 01:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJrVm0Tb3EVF for ; Thu,  7 May 2020 01:23:55 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0D83A0955 for ; Thu,  7 May 2020 01:23:55 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id B51C82539 for ; Thu,  7 May 2020 08:23:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588839831; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=T9e5AzItTXxK2hP99gQdeqPDZTON7V6mgex143y3Vqc=; b=jpCB+hPgQIZiPaoKEJlgUEHfR3WYcpykSTP9avtKMlGWzp03480oamaOHiQKk1Ex22iQYF JNyD5XBGiR2v/OejVUsB5d8eNhd9mxa/WABW7JY6Cdvei4wfKcYDuuV0FXBq/0BbJciKHH eFVMX5vwWaYXLCM+t4zjt2lJ1WuglR8=
To: oauth@ietf.org
References: <158608868945.18323.557347538112056951@ietfa.amsl.com> <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr>
From: Daniel Fett 
Message-ID: 
Date: Thu, 7 May 2020 10:23:50 +0200
MIME-Version: 1.0
In-Reply-To: <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr>
Content-Type: multipart/alternative; boundary="------------A1CF9FCE2247BD84AF84F95E"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588839831; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=T9e5AzItTXxK2hP99gQdeqPDZTON7V6mgex143y3Vqc=; b=HlxGRBv/xRudyhvmSPzKAkZ82FCmE57Fx0ZbYlojjMucv4VZKwhp27fEZdsZC+G/Immbip 5Ru3CaF3750+Fx7nn7IiJJqJPTq57WOGx0JsgKxDVqgBU4SvvhNOHIOz2/ZuJaRM4mG40t AisoKTLCcr+uMDKhTqlb6ZiVQhVvE64=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588839831; a=rsa-sha256; cv=none; b=S+GFScKxPXMfjKs1aDxpOrEc6Xdqfzh9LFA9LEC8BWgNMni4bjqt+mxTsOVI5K01eExHqH fqq2lo+e8/Ceq5C+RrR0HTGJDBm1zCkclox9euA8qAgCkmi6VDRKyOAcGuxJRTO/24dgd6 ZqIAsVb/cdZkq1W34+KrM8+XHEdpPkg=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 May 2020 08:23:58 -0000

This is a multi-part message in MIME format.
--------------A1CF9FCE2247BD84AF84F95E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Hi Denis,

Am 05.05.20 um 17:19 schrieb Denis:
> Comments on draft-ietf-oauth-security-topics-15
>
> 1) Historically, the acronym RO (Resource Owner) has been used but is
> still used in this document.
>     Since a client is not necessarily any more a RO, it would be more
> adequate to use the word "Client"
>     instead of "RO"  in this document.
>
The terms Resource Owner and Client are clearly defined in RFC6749 and
refer to two different entities.
>
>
> 2) The structure of the document is the following:
>
>    1.  Introduction
>    2.  Recommendations
>    3.  The Updated OAuth 2.0 Attacker Model
>
> It is rather odd to have recommendations placed before the Attacker
> Model. Before providing solutions to some problems,
> it is important to understand what the problems are. The Updated OAuth
> 2.0 Attacker model should be placed after the introduction.
>
> The "most important recommendations of the OAuth working group for
> every OAuth implementor" should be placed after the "Attacks and
> Mitigations" section.
>
This structure was chosen specifically to have the recommendations -
arguably the most important section for everyday users of OAuth - in the
front.
>
>
> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been
> "updated to account for the potentially _dynamic relationships
> involving multiple parties_".
> However, it still misses to address the case of _dynamic relationships
> between clients_, which include scenarios of _collaborative clients_.
>
That is not correct. Web attackers (A1) can participate in the protocol
as one or more users (resource owners) or clients. Of course, these can
collaborate between each other.

> Such a collaboration between clients is possible and should be
> considered in the "updated model".
>
This is considered in the model.
>
> which are human beings, it cannot be assumed that all the human beings
> in the world will necessary be honest. Whether or not Auth 2.0 is able
> or not
> to counter such an attack is another issue.
>
This as well.
>
> In another section, it should be mentioned that OAuth 2.0 is unable to
> counter such an attack.
>
The problem is not that this type of collusion attack is not possible
under the model. The problem is it is not commonly expected that OAuth
protects against this type of attack.

-Daniel

> Stating that such an attack is "out of the scope" of OAuth 2.0 would
> not be an appropriate statement.
>
> It should not be forgotten, that the purpose of this document is to
> inform the reader about _all_ the relevant security issues.
>
> Denis
>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>
>>         Title           : OAuth 2.0 Security Best Current Practice
>>         Authors         : Torsten Lodderstedt
>>                           John Bradley
>>                           Andrey Labunets
>>                           Daniel Fett
>> 	Filename        : draft-ietf-oauth-security-topics-15.txt
>> 	Pages           : 46
>> 	Date            : 2020-04-05
>>
>> Abstract:
>>    This document describes best current security practice for OAuth 2.0.
>>    It updates and extends the OAuth 2.0 Security Threat Model to
>>    incorporate practical experiences gathered since OAuth 2.0 was
>>    published and covers new threats relevant due to the broader
>>    application of OAuth 2.0.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------A1CF9FCE2247BD84AF84F95E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Denis,

    

    


    

    
Am 05.05.20 um 17:19 schrieb Denis:

    

    

      
      
Comments on draft-ietf-oauth-security-topics-15

        
        
 1) Historically, the acronym RO (Resource
            Owner) has been used but is still used in this document. 

                Since a client is not necessarily any more a RO, it
            would be more adequate to use the word "Client" 

                instead of "RO"  in this document.

          

      

    

    The terms Resource Owner and Client are clearly defined in RFC6749
    and refer to two different entities. 

    

      

        
 

            2) The structure of the document is the following:

            

               1.  Introduction 

               2.  Recommendations 

               3.  The Updated OAuth 2.0
            Attacker Model

            

            It is rather odd to have recommendations placed before the
            Attacker Model. Before providing solutions to some problems,
            

            it is important to understand what the problems are. The
            Updated OAuth 2.0 Attacker model should be placed after the
            introduction. 

            

            The "most important recommendations of the OAuth working
            group for every OAuth implementor" should be placed after
            the "Attacks and Mitigations" section.

          

      

    

    This structure was chosen specifically to have the recommendations -
    arguably the most important section for everyday users of OAuth - in
    the front.

    

      

        
 

          

        
3) The "Updated OAuth 2.0 Attacker
            Model" is supposed to have been "updated to account for the
            potentially dynamic relationships involving multiple
              parties". 

            However, it still misses to address the case of dynamic
              relationships between clients, which include scenarios
            of collaborative clients.

          

      

    

    
That is not correct. Web attackers (A1) can participate in the
      protocol as one or more users (resource owners) or clients. Of
      course, these can collaborate between each other.

    

      

        
 Such a collaboration between clients is
            possible and should be considered in the "updated model". 

          

      

    

    This is considered in the model.

    

      

        
 which are human beings, it cannot be assumed
            that all the human beings in the world will necessary be
            honest. Whether or not Auth 2.0 is able or not 

            to counter such an attack is another issue.

          

      

    

    This as well.
    

      

        
 

        
In another section, it should be mentioned that
            OAuth 2.0 is unable to counter such an attack.

          

      

    

    
The problem is not that this type of collusion attack is not
      possible under the model. The problem is it is not commonly
      expected that OAuth protects against this type of attack.

    
-Daniel

    

    

      

        
 Stating that such an attack is "out of the
            scope" of OAuth 2.0 would not be an appropriate
            statement.

          

        
It should not be forgotten, that the purpose of
            this document is to inform the reader about all the
            relevant security issues.

            

            Denis

      

      

        
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-15.txt
	Pages           : 46
	Date            : 2020-04-05

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


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


      

      


      

      

      

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


    

    


    

  


--------------A1CF9FCE2247BD84AF84F95E--


From nobody Thu May  7 05:46:13 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6305E3A0528 for ; Thu,  7 May 2020 05:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTsqfvdJs4JU for ; Thu,  7 May 2020 05:46:08 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C873A053E for ; Thu,  7 May 2020 05:46:06 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d83 with ME id bom4220064FMSmm03om4EE; Thu, 07 May 2020 14:46:05 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 07 May 2020 14:46:05 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: <158608868945.18323.557347538112056951@ietfa.amsl.com> <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr> 
From: Denis 
Message-ID: 
Date: Thu, 7 May 2020 14:46:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C15842C62DFC6B4957AE82AF"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 May 2020 12:46:11 -0000

This is a multi-part message in MIME format.
--------------C15842C62DFC6B4957AE82AF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Daniel,

> Hi Denis,
>
> Am 05.05.20 um 17:19 schrieb Denis:
>> Comments on draft-ietf-oauth-security-topics-15
>>
>> 1) Historically, the acronym RO (Resource Owner) has been used but is 
>> still used in this document.
>>     Since a client is not necessarily any more a RO, it would be more 
>> adequate to use the word "Client"
>>     instead of "RO"  in this document.
>>
> The terms Resource Owner and Client are clearly defined in RFC6749 and 
> refer to two different entities.

RFC 6749 contains the two following definitions:

resource owner
       An entity capable of granting access to a protected resource.
       When the resource owner is a person, it is referred to as an
       end-user.

client
       An application making protected resource requests *on behalf of the**
**      resource owner and* with its authorization.  The term "client" does
       not imply any particular implementation characteristics (e.g.,
       whether the application executes on a server, a desktop, or other
       devices).

The original definition of a client does not appear to be adequate any more.
It is questionable whether the definition of a client from RFC 6749 
should be reused word-to-word.

The original definition of a client mentions the resource owner and 
misses to mention the authorisation server.
I wonder whether the use of the wording "on behalf of the resource 
owner" is really adequate. A client is not
impersonating the resource owner.

A client is an application *using an authorisation server *for 
performing protected resource requests
that will be granted or not by a resource owner.

A new definition for the term client should be adopted for this 
document.  However, you are right, the two wordings shall remain.

>> 2) The structure of the document is the following:
>>
>> 1.Introduction
>> 2.Recommendations
>> 3.The Updated OAuth 2.0 Attacker Model
>>
>> It is rather odd to have recommendations placed before the Attacker 
>> Model. Before providing solutions to some problems,
>> it is important to understand what the problems are. The Updated 
>> OAuth 2.0 Attacker model should be placed after the introduction.
>>
>> The "most important recommendations of the OAuth working group for 
>> every OAuth implementor" should be placed after the "Attacks and 
>> Mitigations" section.
>>
> This structure was chosen specifically to have the recommendations - 
> arguably the most important section for everyday users of OAuth - in 
> the front.

This means that most readers will only read the recommendations section 
placed upfront and are likely to ignore the other sections,
in particular the Updated OAuth 2.0 Attacker Model. They will thus kept 
ignorant of attacks that cannot be countered using the "Best Practices".
They may then believe that their implementations are secure whereas it 
will not be the case.

>>
>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
>> "updated to account for the potentially _dynamic relationships 
>> involving multiple parties_".
>> However, it still misses to address the case of _dynamic 
>> relationships between clients_, which include scenarios of 
>> _collaborative clients_.
>>
> That is not correct. Web attackers (A1) can participate in the 
> protocol as one or more users (resource owners) or clients. Of course, 
> these can collaborate between each other.
>
Section 3 states:

*OAuth MUST ensure that* the authorization of the resource owner (RO)  
(with a user agent) at the authorization server (AS) and
    the subsequent usage of the access token at the resource server (RS) 
*is protected _at least_ against the following attackers*:

   *  (A1) *Web Attackers *(...)

If a collaboration / collusion between clients were covered under this 
case, then it would mean that *OAUTH MUST provide a protection for it*,
whereas this is technically impossible.

Since AOuth is unable to protect against a collusion attack between 
clients, the collusion attack cannot belong to this section, in 
particular under (A1).

Section 3 is confusing the threat model with the resistance of OAuth to 
these threats.

At this time, an RFC reader may not catch the fact that a collusion 
attack between clients may ever exist and thus may not
grasp the fact that this kind of attack cannot be countered by OAuth, 
even when following the Best Practices.

The "Updated OAuth 2.0 Attacker Model" does not take into "account for 
the potentially _dynamic relationships involving multiple parties_".
as it is advertised, in particular the case of _dynamic relationships 
between clients_ which include the case of _collaborative clients_.

The text currently does not  incorporate words like "collusion", 
"colluding", whereas it should. The text should clearly indicate that
a protection against a collusion between clients is currently not 
possible using OAuth.

>> Such a collaboration between clients is possible and should be 
>> considered in the "updated model".
>>
> This is considered in the model.

See my comments above. While promised by the text, the case of 
collaborative clients is not considered in the model.

>> which are human beings, it cannot be assumed that all the human 
>> beings in the world will necessary be honest. Whether or not Auth 2.0 
>> is able or not
>> to counter such an attack is another issue.
>>
> This as well. 

As said above, the model should only express the threats (or the 
possible attacks) and another section should indicate which threats 
cannot countered.

>> In another section, it should be mentioned that OAuth 2.0 is unable 
>> to counter such an attack.
>>
> The problem is not that this type of collusion attack is not possible 
> under the model. The problem is it is not commonly expected that OAuth 
> protects against this type of attack.
>
RFC readers who have not followed or participated to this thread will 
not necessarily know that OAuth does not protect against this type of 
attack.

The purpose of this document is to inform the reader about _all_ known 
types of attacks, whether they can be defeated or not by OAuth 2.0.

Denis

> -Daniel
>
>> Stating that such an attack is "out of the scope" of OAuth 2.0 would 
>> not be an appropriate statement.
>>
>> It should not be forgotten, that the purpose of this document is to 
>> inform the reader about _all_ the relevant security issues.
>>
>> Denis
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>>
>>>          Title           : OAuth 2.0 Security Best Current Practice
>>>          Authors         : Torsten Lodderstedt
>>>                            John Bradley
>>>                            Andrey Labunets
>>>                            Daniel Fett
>>> 	Filename        : draft-ietf-oauth-security-topics-15.txt
>>> 	Pages           : 46
>>> 	Date            : 2020-04-05
>>>
>>> Abstract:
>>>     This document describes best current security practice for OAuth 2.0.
>>>     It updates and extends the OAuth 2.0 Security Threat Model to
>>>     incorporate practical experiences gathered since OAuth 2.0 was
>>>     published and covers new threats relevant due to the broader
>>>     application of OAuth 2.0.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------C15842C62DFC6B4957AE82AF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Daniel,

    


    

    

      
      
Hi Denis,

      

      


      

      
Am 05.05.20 um 17:19 schrieb Denis:

      

      

        
        
Comments on draft-ietf-oauth-security-topics-15

          
          
 1) Historically, the acronym RO (Resource
              Owner) has been used but is still used in this document. 

                  Since a client is not necessarily any more a RO, it
              would be more adequate to use the word "Client" 

                  instead of "RO"  in this document.

            

        

      

      The terms Resource Owner and Client are clearly defined in RFC6749
      and refer to two different entities. 

    

    
RFC 6749 contains the two following definitions:

    
resource owner

            An entity capable of granting access to a protected
      resource.

            When the resource owner is a person, it is referred to as an

            end-user.

    

    
client

            An application making protected resource requests on
        behalf of the

            resource owner and with its authorization.  The
      term "client" does

            not imply any particular implementation characteristics
      (e.g.,

            whether the application executes on a server, a desktop, or
      other

            devices).

    
The original definition of a client does not appear to be
      adequate any more.

      It is questionable whether the definition of a client from RFC
      6749 should be reused word-to-word.

    
The original definition of a client mentions the resource owner
      and misses to mention the authorisation server.

      I wonder whether the use of the wording "on behalf of the resource
      owner" is really adequate. A client is not 

      impersonating the resource owner.

      

      A client is an application using an authorisation server for
      performing protected resource requests 

      that will be granted or not by a resource owner.

    
A new definition for the term client should be adopted for this
      document.  However, you are right, the two wordings shall remain.

    

    

      

        

          
 2) The structure of the document is the
              following:

              

                 1.  Introduction 

                 2.  Recommendations 

                 3.  The Updated OAuth
              2.0 Attacker Model

              

              It is rather odd to have recommendations placed before the
              Attacker Model. Before providing solutions to some
              problems, 

              it is important to understand what the problems are. The
              Updated OAuth 2.0 Attacker model should be placed after
              the introduction. 

              

              The "most important recommendations of the OAuth working
              group for every OAuth implementor" should be placed after
              the "Attacks and Mitigations" section.

            

        

      

      This structure was chosen specifically to have the recommendations
      - arguably the most important section for everyday users of OAuth
      - in the front.

    

    
This means that most readers will only read the recommendations
      section placed upfront and are likely to ignore the other
      sections, 

      in particular the Updated OAuth 2.0 Attacker Model. They will thus
        kept ignorant of attacks that cannot be countered using the
        "Best Practices".

        They may then believe that their implementations are secure
        whereas it will not be the case.

    

    

      

        


          
3) The "Updated OAuth 2.0 Attacker
              Model" is supposed to have been "updated to account for
              the potentially dynamic relationships involving
                multiple parties". 

              However, it still misses to address the case of dynamic
                relationships between clients, which include
              scenarios of collaborative clients.

            

        

      

      
That is not correct. Web attackers (A1) can participate in the
        protocol as one or more users (resource owners) or clients. Of
        course, these can collaborate between each other.

    

    
Section 3 states:

    
   OAuth MUST ensure that the authorization of the
      resource owner (RO)  (with a user agent) at the authorization
      server (AS) and 

         the subsequent usage of the access token at the resource server
      (RS) is protected at least against the following
        attackers:

    
  *  (A1) Web Attackers (...)

    
If a collaboration / collusion between clients were covered under
      this case, then it would mean that OAUTH MUST provide a
        protection for it, 

      whereas this is technically impossible.

    

    
Since AOuth is unable to protect against a collusion attack
      between clients, the collusion attack cannot belong to this
      section, in particular under (A1).

    
Section 3 is confusing the threat model with the resistance of
      OAuth to these threats.

    
At this time, an RFC reader may not catch the fact that a
      collusion attack between clients may ever exist and thus may not 

      grasp the fact that this kind of attack cannot be countered by
      OAuth, even when following the Best Practices.

    
The "Updated OAuth 2.0 Attacker Model" does not take
        into "account for the potentially dynamic relationships
          involving multiple parties". 

        as it is advertised, in particular the case of dynamic
          relationships between clients which include the case of collaborative
          clients.

    
The text currently does not  incorporate words like "collusion",
      "colluding", whereas it should. The text should clearly indicate
      that 

      a protection against a collusion between clients is currently not
      possible using OAuth.

    

      

        

          
 Such a collaboration between clients is
              possible and should be considered in the "updated model".
              

            

        

      

      This is considered in the model.

    

    
See my comments above. While promised by the text, the case of
      collaborative clients is not considered in the model.

    

      

        

          
 which are human beings, it cannot be assumed
              that all the human beings in the world will necessary be
              honest. Whether or not Auth 2.0 is able or not 

              to counter such an attack is another issue.

            

        

      

      This as well. 

    
As said above, the model should only express the threats (or the
      possible attacks) and another section should indicate which
      threats cannot countered.  

    

    

      

        

          
 

          
In another section, it should be mentioned
              that OAuth 2.0 is unable to counter such an attack.

            

        

      

      
The problem is not that this type of collusion attack is not
        possible under the model. The problem is it is not commonly
        expected that OAuth protects against this type of attack.

    

    
RFC readers who have not followed or participated to this thread
      will not necessarily know that OAuth does not protect against this
      type of attack.

    
The purpose of this document is to inform the reader
        about all known types of attacks, whether they can be
        defeated or not by OAuth 2.0.

    
Denis

    

      
-Daniel

      

      

        

          
 Stating that such an attack is "out of the
              scope" of OAuth 2.0 would not be an
              appropriate statement.

            

          
It should not be forgotten, that the purpose
              of this document is to inform the reader about all
              the relevant security issues.

              

              Denis

        

        

          
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-15.txt
	Pages           : 46
	Date            : 2020-04-05

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


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


        

        


        

        

        

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


      

      


      

      

      

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


    

    


    

  


--------------C15842C62DFC6B4957AE82AF--


From nobody Thu May  7 06:32:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122513A083A for ; Thu,  7 May 2020 06:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85E9aPDDxWA3 for ; Thu,  7 May 2020 06:32:15 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106153A0834 for ; Thu,  7 May 2020 06:32:15 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id r3so202133qvm.1 for ; Thu, 07 May 2020 06:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:date:message-id:subject:from:to:user-agent; bh=wdIqVQWb4u5Fh/Cg0wbclNNCNAccyYAw1dlHzLe+aQo=; b=cYICLet49gY05k09j5SS2+xjqkzyG2HZotIZLHGqFMiB5Q+cQ04XUNlwmIypb41Nrx RyDVomanu2iJbb2bkaxmXNz4uohJUFfC3nlMR4eael+lQaC0EJCxASj9BpyEPuCZj9mD WRvn7bRuDj95ealMFB8B0RWN42nxleymEr4udkqL3x1TF/K6U6lAM4cduRfP/3tiLWZe cvsPPQH5Us7hD5DOVRqruLlR2HsEPG2YXGtygMtKpuz+K9D/TB++LCMqGWrRfT8liVqn OqtUrkJBpGg/R9GxqjaJsfox7JH+wdQImV8SxYDXFJRvy+pIYgI9yvD+b3305/zUORM7 46Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :user-agent; bh=wdIqVQWb4u5Fh/Cg0wbclNNCNAccyYAw1dlHzLe+aQo=; b=XYs9le0/tKFl5EvB29VNXMf7ThJrrLK2w9WksraqxMZ1Hzbx6VutsET6zsQJsTbxaF 4XvVK7HGfC9hilYOoGawcxxRfmGU/hfBMK6hiGFc7zv9Yv8cgLAYk/4iRAp1aZDa28vO PJOcviPnUgojvwXffWP6yvHpMTkVTWiSfZcY2VbuxrXSKN3nJlwSJvxTfuIlpT+HLutJ sXlpJGQTDI7VirZ/9/9po7d6KnNzn5hCSDGlTECLqlw/Hbf71mPhwjIqAe9iXm9tlWUc yr0aYtaBDzGHjBYzs/js5AxYlY7QOlc39JZT4gKm1DYvR0l/QoLg1dz7WlvQoSnWtJ7z TltA==
X-Gm-Message-State: AGi0PuZQAW/CMSdDtlzEYc+jGg1iht8tDqpwE4OJUA/rpKvE+EiZPonX HVWiJd/eJe1W0lheY6UztQFvgJTmgxc=
X-Google-Smtp-Source: APiQypKBMHwYWSQB5Fa57iXfGLGH9wFPd5US83SltCSYnL2iy1JiIRvZ28KTxcP5UZaC6YNnQ5xzNQ==
X-Received: by 2002:a0c:facb:: with SMTP id p11mr13457294qvo.17.1588858333626;  Thu, 07 May 2020 06:32:13 -0700 (PDT)
Received: from [10.0.1.2] (pool-74-103-207-160.prvdri.ftas.verizon.net. [74.103.207.160]) by smtp.gmail.com with ESMTPSA id h6sm4110155qtd.79.2020.05.07.06.32.12 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 06:32:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_5717593.051899211264"
MIME-Version: 1.0
Date: Thu, 07 May 2020 09:32:13 -0400
Message-ID: 
From: "Brock Allen" 
To: "" 
User-Agent: Mailbird/2.8.5.0
X-Mailbird-ID: Mailbird-635821db-1f3a-4def-b157-a92bb7dddcdf@gmail.com
Archived-At: 
Subject: [OAUTH-WG] draft-ietf-oauth-jwsreq-21
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 May 2020 13:32:18 -0000

------=_NextPart_5717593.051899211264
Content-Type: text/plain;
 charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Perhaps quite late, but a few comments/questions related to this:

1) When decoded, all the JWT samples are missing the "typ" claim from the h=
eader, which I think should be "oauth.authz.req+jwt".

2) When validating the JAR if we are to validate the "typ" then this would =
be incompatible with OIDC's request object, I think?

3) When the JAR is passed by reference, then the HTTP response Content-Type=
 of=C2=A0"application/oauth.authz.req+jwt" would also seem to break or be i=
ncompatible with OIDC's request object passed by reference?

There might need to be clarification when mixing this w/ an OIDC OP impleme=
ntation.=C2=A0

TIA

-Brock

------=_NextPart_5717593.051899211264
Content-Type: text/html;
 charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Perhaps quite late, but a few comments/questio=
ns related to this:

1) When decoded, all the JWT samples=
 are missing the "typ" claim from the header, which I think should be "oaut=
h.authz.req+jwt".

2) When validating the JAR if we=
 are to validate the "typ" then this would be incompatible with OIDC's requ=
est object, I think?

3) When the JAR is passed by =
reference, then the HTTP response Content-Type of "application/oauth.a=
uthz.req+jwt" would also seem to break or be incompatible with OIDC's reque=
st object passed by reference?

There might need to=
 be clarification when mixing this w/ an OIDC OP implementation. 

TIA

=
-Brock


------=_NextPart_5717593.051899211264--


From nobody Thu May  7 09:23:02 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A173A0AA0 for ; Thu,  7 May 2020 09:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kElB56-gpK6K for ; Thu,  7 May 2020 09:22:57 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6563A0A93 for ; Thu,  7 May 2020 09:22:57 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 28C8F26C2 for ; Thu,  7 May 2020 16:22:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588868573; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4yMML/IdeuOfLPPCF+pILDyi+6lL6YNFzMN7bE3tzOo=; b=diHekUAGIjeCFNgCyaMgwyXFJ5Esoy9K8aEY9sEnIayKIIPskn4QOKDpo4UbIYdF4CLvIn x6eXeNDNXVVvH8BnswUBy1WwP6meej4FW56+kGf4HwoRR5gDQlqYjYyF98MnfhRrOdnFPJ 5w7qylRbt7bsG04HYZvr08FgHa+axm8=
To: oauth@ietf.org
References: <158608868945.18323.557347538112056951@ietfa.amsl.com> <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr>  
From: Daniel Fett 
Message-ID: <18e38735-ae9f-c41b-0cda-b2818a1038dc@danielfett.de>
Date: Thu, 7 May 2020 18:22:52 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E3AF5DC2981EC9C2E7E838F1"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588868573; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4yMML/IdeuOfLPPCF+pILDyi+6lL6YNFzMN7bE3tzOo=; b=Yir8l6y2HF0pWCVB9894u2ce7ULAcgY20cG1n3eVwLXHN55X0aOndZM/hgmjK0N6EuN9wq eChoge6yLIFeIayx1tiB90ahfTky4FV7T2zeHOB9h7g11YxfZfkow6saSKliEbAPnIfHg4 TWsjlWyWMpSnao9OVRlGQ9XVKRhW/lk=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588868573; a=rsa-sha256; cv=none; b=MFTsseV0UDMos7uRurCIWzrHEK8iHDi/vBo8FDFm0o6/0zWn/4BOUXRjsCLKp/wEc1k5D9 DT9QtvLy4lX0LfsJf4PzT6k3RIqPLhO/eq/WMrD/d9KTgUwySa2pG4XUHML3/wsmsmxPiJ 03emVJRqeZlznRRuMSxAfyoM92f4rVk=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 May 2020 16:23:00 -0000

This is a multi-part message in MIME format.
--------------E3AF5DC2981EC9C2E7E838F1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Hi Denis,

Am 07.05.20 um 14:46 schrieb Denis:
> (...)
>
> A new definition for the term client should be adopted for this
> document.  However, you are right, the two wordings shall remain.
>
I cannot follow any of this, sorry.

>>>
>>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been
>>> "updated to account for the potentially _dynamic relationships
>>> involving multiple parties_".
>>> However, it still misses to address the case of _dynamic
>>> relationships between clients_, which include scenarios of
>>> _collaborative clients_.
>>>
>> That is not correct. Web attackers (A1) can participate in the
>> protocol as one or more users (resource owners) or clients. Of
>> course, these can collaborate between each other.
>>
> Section 3 states:
>
>    *OAuth MUST ensure that* the authorization of the resource owner
> (RO)  (with a user agent) at the authorization server (AS) and
>    the subsequent usage of the access token at the resource server
> (RS) *is protected _at least_ against the following attackers*:
>
>   *  (A1) *Web Attackers *(...)
>
> If a collaboration / collusion between clients were covered under this
> case, then it would mean that *OAUTH MUST provide a protection for it*,
> whereas this is technically impossible.
>
You are confusing the attacker model with the security goals (aka
security properties).

A commonly accepted security property for OAuth would be:

"An attacker should not be able to obtain access to or use a protected
resource protected by an uncompromised AS if that resource is only used
by an honest user with an uncompromised client and user agent."

(roughly equivalent to the one in
https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)

Being resistant to collusion attacks is not a commonly accepted/expected
security property.

So: Yes, attackers are free to collude, and that is part of the model.
No, that is not a problem, as they are not breaking anything anyone
would expect.

-Daniel


> Since AOuth is unable to protect against a collusion attack between
> clients, the collusion attack cannot belong to this section, in
> particular under (A1).
>
> Section 3 is confusing the threat model with the resistance of OAuth
> to these threats.
>
> At this time, an RFC reader may not catch the fact that a collusion
> attack between clients may ever exist and thus may not
> grasp the fact that this kind of attack cannot be countered by OAuth,
> even when following the Best Practices.
>
> The "Updated OAuth 2.0 Attacker Model" does not take into "account for
> the potentially _dynamic relationships involving multiple parties_".
> as it is advertised, in particular the case of _dynamic relationships
> between clients_ which include the case of _collaborative clients_.
>
> The text currently does not  incorporate words like "collusion",
> "colluding", whereas it should. The text should clearly indicate that
> a protection against a collusion between clients is currently not
> possible using OAuth.
>
>>> Such a collaboration between clients is possible and should be
>>> considered in the "updated model".
>>>
>> This is considered in the model.
>
> See my comments above. While promised by the text, the case of
> collaborative clients is not considered in the model.
>
>>> which are human beings, it cannot be assumed that all the human
>>> beings in the world will necessary be honest. Whether or not Auth
>>> 2.0 is able or not
>>> to counter such an attack is another issue.
>>>
>> This as well. 
>
> As said above, the model should only express the threats (or the
> possible attacks) and another section should indicate which threats
> cannot countered. 
>
>>> In another section, it should be mentioned that OAuth 2.0 is unable
>>> to counter such an attack.
>>>
>> The problem is not that this type of collusion attack is not possible
>> under the model. The problem is it is not commonly expected that
>> OAuth protects against this type of attack.
>>
> RFC readers who have not followed or participated to this thread will
> not necessarily know that OAuth does not protect against this type of
> attack.
>
> The purpose of this document is to inform the reader about _all_ known
> types of attacks, whether they can be defeated or not by OAuth 2.0.
>
> Denis
>
>> -Daniel
>>
>>> Stating that such an attack is "out of the scope" of OAuth 2.0 would
>>> not be an appropriate statement.
>>>
>>> It should not be forgotten, that the purpose of this document is to
>>> inform the reader about _all_ the relevant security issues.
>>>
>>> Denis
>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>>>
>>>>         Title           : OAuth 2.0 Security Best Current Practice
>>>>         Authors         : Torsten Lodderstedt
>>>>                           John Bradley
>>>>                           Andrey Labunets
>>>>                           Daniel Fett
>>>> 	Filename        : draft-ietf-oauth-security-topics-15.txt
>>>> 	Pages           : 46
>>>> 	Date            : 2020-04-05
>>>>
>>>> Abstract:
>>>>    This document describes best current security practice for OAuth 2.0.
>>>>    It updates and extends the OAuth 2.0 Security Threat Model to
>>>>    incorporate practical experiences gathered since OAuth 2.0 was
>>>>    published and covers new threats relevant due to the broader
>>>>    application of OAuth 2.0.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------E3AF5DC2981EC9C2E7E838F1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Denis,

    

    


    

    
Am 07.05.20 um 14:46 schrieb Denis:

    

    

      
      

      (...)

      
A new definition for the term client should be adopted for this
        document.  However, you are right, the two wordings shall
        remain.

      

    

    
I cannot follow any of this, sorry.

    

      

        

          


            
3) The "Updated OAuth 2.0 Attacker
                Model" is supposed to have been "updated to account for
                the potentially dynamic relationships involving
                  multiple parties". 

                However, it still misses to address the case of dynamic
                  relationships between clients, which include
                scenarios of collaborative clients.

              

          

        

        
That is not correct. Web attackers (A1) can participate in
          the protocol as one or more users (resource owners) or
          clients. Of course, these can collaborate between each other.

      

      
Section 3 states:

      
   OAuth MUST ensure that the authorization of the
        resource owner (RO)  (with a user agent) at the authorization
        server (AS) and 

           the subsequent usage of the access token at the resource
        server (RS) is protected at least against the
          following attackers:

      
  *  (A1) Web Attackers (...)

      
If a collaboration / collusion between clients were covered
        under this case, then it would mean that OAUTH MUST provide
          a protection for it, 

        whereas this is technically impossible.

      

    

    
You are confusing the attacker model with the security goals (aka
      security properties).

    
A commonly accepted security property for OAuth would be:

    
"An attacker should not be able to obtain access to or use a
      protected resource protected by an uncompromised AS if that
      resource is only used by an honest user with an uncompromised
      client and user agent."

    
(roughly equivalent to the one in
https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)

    

    
Being resistant to collusion attacks is not a commonly
      accepted/expected security property.

    
So: Yes, attackers are free to collude, and that is part of the
      model. No, that is not a problem, as they are not breaking
      anything anyone would expect.

    

    
-Daniel

    

    


    

    

      
 

      
Since AOuth is unable to protect against a collusion attack
        between clients, the collusion attack cannot belong to this
        section, in particular under (A1).

      
Section 3 is confusing the threat model with the resistance of
        OAuth to these threats.

      
At this time, an RFC reader may not catch the fact that a
        collusion attack between clients may ever exist and thus may not
        

        grasp the fact that this kind of attack cannot be countered by
        OAuth, even when following the Best Practices.

      
The "Updated OAuth 2.0 Attacker Model" does not take
          into "account for the potentially dynamic relationships
            involving multiple parties". 

          as it is advertised, in particular the case of dynamic
            relationships between clients which include the case of
          collaborative clients.

      
The text currently does not  incorporate words like
        "collusion", "colluding", whereas it should. The text should
        clearly indicate that 

        a protection against a collusion between clients is currently
        not possible using OAuth.

      

        

          

            
 Such a collaboration between clients is
                possible and should be considered in the "updated
                model". 

              

          

        

        This is considered in the model.

      

      
See my comments above. While promised by the text, the case of
        collaborative clients is not considered in the model.

      

        

          

            
 which are human beings, it cannot be
                assumed that all the human beings in the world will
                necessary be honest. Whether or not Auth 2.0 is able or
                not 

                to counter such an attack is another issue.

              

          

        

        This as well. 

      
As said above, the model should only express the threats (or
        the possible attacks) and another section should indicate which
        threats cannot countered.  

      

      

        

          

            
 

            
In another section, it should be mentioned
                that OAuth 2.0 is unable to counter such an attack.

              

          

        

        
The problem is not that this type of collusion attack is not
          possible under the model. The problem is it is not commonly
          expected that OAuth protects against this type of attack.

      

      
RFC readers who have not followed or participated to this
        thread will not necessarily know that OAuth does not protect
        against this type of attack.

      
The purpose of this document is to inform the
          reader about all known types of attacks, whether they
          can be defeated or not by OAuth 2.0.

      
Denis

      

        
-Daniel

        

        

          

            
 Stating that such an attack is "out of the
                scope" of OAuth 2.0 would not be an
                appropriate statement.

              

            
It should not be forgotten, that the
                purpose of this document is to inform the reader about all
                the relevant security issues.

                

                Denis

          

          

            
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-15.txt
	Pages           : 46
	Date            : 2020-04-05

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


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


          

          


          

          

          

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


        

        


        

        

        

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


      

      


      

      

      

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


    

    


    

  


--------------E3AF5DC2981EC9C2E7E838F1--


From nobody Thu May  7 11:56:51 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761FF3A08B3 for ; Thu,  7 May 2020 11:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYLz5fG3i9Ue for ; Thu,  7 May 2020 11:56:46 -0700 (PDT)
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F253A0894 for ; Thu,  7 May 2020 11:56:45 -0700 (PDT)
Received: by mail-vk1-xa2d.google.com with SMTP id v23so1761895vke.13 for ; Thu, 07 May 2020 11:56:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=w57QxFSZ9+zL13TkMMMleTNmf935OJWiQFcvkWxcgTU=; b=UBC4L5U4fWzLHsbeOovh6KUca14JfAXpKdCvZ2kr3oYzmctpHH3cKM7cKROwNvdAbx cqGKxw9PCrwt2kCKfhdMwh9bWhZmPVNsvITKPobohTmPpYi/jAE0vEv5/syLiHyd8rWE KV/CAt2xEkEQvvzdGLheXtiBm6sFTc1BJnsbE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=w57QxFSZ9+zL13TkMMMleTNmf935OJWiQFcvkWxcgTU=; b=KUHlXbqcEB2MOjNdo57oeASw+g5vFPXg46OcS6aP8y6I718Kbvt5GQU7sVGUU/HgjQ Kzc84Njb8TRqtRk0yuUb+RidYGcL2Eq42e2xmAArU5od45lD1werO15fPjhlZJ5nt05L 9Q3/IQRfixnMYfr7UEIom4FpXtS+VlHEu1NDjbJcJWhu77uOAdehKjdaL7iiFHkZrvw8 7EHwFz/sHlEtthbUgJNN9l9+g+GUiLx9dqaOxSWuFJwVcJbXdd1iEcOve9ublTrHtwm6 TvIWy05bKjVTlNcyHz9v8gl9aPKbRI+gpgbQ0f5Dpdh+4YOZqhupmeIoyrqUMXwxDTxt FMJg==
X-Gm-Message-State: AGi0PuaSxZaAyDH1D5i/7ceDa7UOaDZFl/flUd8+/DLs5nm1EZJrmsCi FRFGHnKL37bF59jQi8t4ywUDxBTmtfyX2gHntw0SZw==
X-Google-Smtp-Source: APiQypI+ozJXihlBMIy2XP1x6/XuwTh23MqL8O1Q9EQ7m3NqC/p9eFRzR9jxsajnz+lY6zPcGjWkoaXvF+tEnHarYbc=
X-Received: by 2002:ac5:c76d:: with SMTP id c13mr13143948vkn.3.1588877804342;  Thu, 07 May 2020 11:56:44 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Prabath Siriwardena 
Date: Thu, 7 May 2020 11:56:34 -0700
Message-ID: 
To: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="0000000000001eaa2105a51371e9"
Archived-At: 
Subject: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 May 2020 18:56:49 -0000

--0000000000001eaa2105a51371e9
Content-Type: text/plain; charset="UTF-8"

Hi all,

Can we say in [1], that the AS should add the value of *state* parameter
from the authorization request (if present), to the JWT access token it
generates?

This will help to address token injection issue [2], with respect to the
implicit grant type.

Appreciate your thoughts on this.

[1]: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
[2]:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.6

Thanks
-Prabath

On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef 
wrote:

> Hi all,
>
>
>
> This is a 3rd working group last call for "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>
>
>
> Please send your comments to the OAuth mailing list by May 12, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000001eaa2105a51371e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,

Can we say in [1], t=
hat the AS should add the value of state parameter from the authoriz=
ation request (if present), to the JWT access token it generates?

This will help to address token injection issue [2], with r=
espect to the implicit grant type.

Appreciate your=
 thoughts on this.


Thanks
-Prabath

On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=

Hi all,
=C2=A0
This is a 3rd working group last call for "JSON =
Web Token (JWT) Profile for OAuth 2.0 Access Tokens".
=C2=A0
Here is the document:
https://tools.ietf.org/html/draft=
-ietf-oauth-access-token-jwt-07=C2=A0=C2=A0
=C2=A0
Please send your comments to the OAuth mailing list by May 1=
2, 2020.
=C2=A0
Regards,
=C2=A0Rifaat & Hannes

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000001eaa2105a51371e9--


From nobody Thu May  7 13:29:46 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DA53A0D66 for ; Thu,  7 May 2020 13:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eYMaQOS2vCc for ; Thu,  7 May 2020 13:29:42 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBC33A0D63 for ; Thu,  7 May 2020 13:29:41 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id fu13so3146006pjb.5 for ; Thu, 07 May 2020 13:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=Tlo/D8XYULWbKvg5+bABHM3KS9fKNgZKvVMS7t0p0eI=; b=JIfCErmFQurMe+hVaO74lKGTQ3dMBkM5QqnGyTDeZsf01FmvXB5KNX2PwJHNqE+KFF POcX58aATerAPzRXXl/3kH7aFuZp3i0fpaCWdF3eM3oB+qEwfC+9ZlIBLDfHCD0QIUhz /+sOV1BkK7KP9YAg2wK3h1RdcnNcRWs+LKKZgZzjdt08PyFwux7qmyUYn0vUPg5KWWnU SoJrydD5KzIEVXFUCLG5pKNBL0VLs/5yzd2htU8UCHHHvCak7HPyvSiaV730OzGQatl2 dvdBlWbKuEL5jzWfZvUvXqZU7bdLU+m+Cs/uh3jtppVL4IG2JPLalx+6KejWyAA2seOs IIww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=Tlo/D8XYULWbKvg5+bABHM3KS9fKNgZKvVMS7t0p0eI=; b=bgZXdcV3F+usZhSDQV0mRVxerIfbt8DPNXb/16U3iI5IsyzY1XPobJ22KXWWImK4W1 fq8kBOO9W9ztpP2Qx28UmA75VqTnxOudxYuYfC6hoUA564CFCi4tnLhAikvVhsE2zO9R WnbfoxxkXyCRphHvFGlFONl5WAV7xs/RTTYuPwnWecxOuIxYHHYTxvN81RX9qWxoa6Oo rg+PbiWitsckLMeKUc2DGZeej2CB4+6AwuX++KlELmcbTsIXNlxNPfxGVpZJsv2DARbT hsF+QaGW+qr4wxRLta9ANT41AYt2DvxzXhHUcWLOkn9LO2RD9/7tWJC/0Po4qNgR/weQ PzEA==
X-Gm-Message-State: AGi0PuZzGm5xzHyVh9BRb+7+AJZRMSxGoz0azBIQn7zFu0O+6Dciw864 77uovjUL9kUP9z7YTA+9ZMfg0Q==
X-Google-Smtp-Source: APiQypJJgaEdVKLdCz6nGRuJiw/LjsnVi8CVU4EIAlpCIDj12tVKxHMxW3Vydz/txTRvWms+8itRIw==
X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr14706412plb.235.1588883380851;  Thu, 07 May 2020 13:29:40 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id e11sm5765851pfl.85.2020.05.07.13.29.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 13:29:40 -0700 (PDT)
From: Vittorio Bertocci 
To: Prabath Siriwardena , Rifaat Shekh-Yusef , oauth 
Thread-Topic: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT
Thread-Index: AQHWJKHhl0Ukw7EDckG/tFQCgawZQqidEzCF
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 7 May 2020 20:29:38 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB15017968B740A220A3896A7AAEA50MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 May 2020 20:29:45 -0000

--_000_MWHPR19MB15017968B740A220A3896A7AAEA50MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Prabath,
Thanks for your comment! Here are my thoughts.
I don=92t believe embedding the state in the AT would help. The state is ge=
nerated (hence verified, if used for protection) by the client, but the con=
tent of the AT is really meant for the RS, which has no direct knowledge of=
 what the state value should be, not in the first nor all the subsequent us=
es of the AT within its validity period. Also, the client itself is forbidd=
en to inspect the content of the access token- you can find the details beh=
ind that in recent discussions on the list.
I=92ll add to this that the implicit grant is on its way out of the grants =
stage, hence doing major changes to accommodate its quirks wouldn=92t give =
a lot of ROI.
HTH
Thanks!
V.

From: OAuth  on behalf of Prabath Siriwardena 
Date: Thursday, May 7, 2020 at 11:56
To: Rifaat Shekh-Yusef , oauth 
Subject: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state =
into the JWT

Hi all,

Can we say in [1], that the AS should add the value of state parameter from=
 the authorization request (if present), to the JWT access token it generat=
es?

This will help to address token injection issue [2], with respect to the im=
plicit grant type.

Appreciate your thoughts on this.

[1]: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
[2]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#sectio=
n-4.6

Thanks
-Prabath

On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef > wrote:
Hi all,

This is a 3rd working group last call for "JSON Web Token (JWT) Profile for=
 OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07

Please send your comments to the OAuth mailing list by May 12, 2020.

Regards,
 Rifaat & Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_MWHPR19MB15017968B740A220A3896A7AAEA50MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Hi Prabath,


Thanks for your comment! Here are my thoughts.<=
/o:p>


I don=92t believe embedding the state in the AT woul=
d help. The state is generated (hence verified, if used for protection) by =
the client, but the content of the AT is really meant for the RS, which has=
 no direct knowledge of what the state
 value should be, not in the first nor all the subsequent uses of the AT wi=
thin its validity period. Also, the client itself is forbidden to inspect t=
he content of the access token- you can find the details behind that in rec=
ent discussions on the list.


I=92ll add to this that the implicit grant is on its=
 way out of the grants stage, hence doing major changes to accommodate its =
quirks wouldn=92t give a lot of ROI.


HTH


Thanks!


V.


 




From=
: OAuth <oauth-b=
ounces@ietf.org> on behalf of Prabath Siriwardena <prabath=3D40wso2.c=
om@dmarc.ietf.org>

Date: Thursday, May 7, 2020 at 11:56

To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, oauth <oaut=
h@ietf.org>

Subject: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding=
 state into the JWT






 








Hi all,






 






Can we say in [1], that the AS should add the value =
of state parameter from the authorization request (if present), to t=
he JWT access token it generates?






 






This will help to address token injection issue [2],=
 with respect to the implicit grant type.






 






Appreciate your thoughts on this.






 








 






Thanks






-Prabath




 






On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef &=
lt;rifaat.ietf@gmail.com> w=
rote:








Hi all,


 


This is a 3rd working =
group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access=
 Tokens".


 


Here is the document:<=
o:p>


ht=
tps://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07 &nb=
sp;


 


Please send your comme=
nts to the OAuth mailing list by May 12, 2020.


 


Regards,

 Rifaat & Han=
nes




_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth












--_000_MWHPR19MB15017968B740A220A3896A7AAEA50MWHPR19MB1501namp_--


From nobody Thu May  7 16:38:55 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FDE3A07B5 for ; Thu,  7 May 2020 16:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFr7TqMP2uAI for ; Thu,  7 May 2020 16:38:49 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2AF3A067A for ; Thu,  7 May 2020 16:38:47 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id j8so2474606iog.13 for ; Thu, 07 May 2020 16:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iw+sAhS8zLum5p3/K5fDO4fVajAI7nrEMjw1dGSYrts=; b=pLqnFFlqM9Pa9Mm43GpfoGkgffL+wryMtKd7lmZePKqRaUgutIjmNe99WZm5t9imO3 O+9YqwIExvbmc+krrllfn5MQKiZAQn8AR/JY+AoXcv/8RaQr7fAYMZagJ05Z41ZIINx/ UvxnTuwJycUCqfj1l3vKcD0GJt4nCGQMfbAOrJq/dgrwQ2bPE0g78uQybMZZpqykyvhx Zv+vVYqDAOavTcV+3UUbjlxNHyBRKV/nV3AJGUR3uVAsehJMGRl2RAKHa4vYNIFoQ6T6 ekstSn7zgBxmgunjG4D1FYvux8t3A35YjOLxNTIBF7MLEU0C+K2PUQ9PKTrwHFLm47Cg zjDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iw+sAhS8zLum5p3/K5fDO4fVajAI7nrEMjw1dGSYrts=; b=BsW14OJjoi1uDYSawKaB0enByeSRppO/53aY9Ma832jyWmzRxIwiQZKibiGm8zwtfK jpvLEiFixanlif28a7NkV8gE/yvcnAs5vOfIT+yn4wb+p2Wo0jH5ZR0iOe29nLtj5r5V pWwBUwdNpiIkopj2fbxBjPpfq4JxvmnoaxQGKsuiBqBhQlSHJUhiELPE6ZQ1X4Ybc6Up l0u0hwe8HPHF24WuKfsQjibUU9BbfeymZ+7SNVTyEu/DqKCiIjuBJOS6dGXc9RY8ccrc FCSYHyKvdOwoMvJl/glQgj36T3+jdsjY6lAoIgCnNincH65HMB2pHjmbaU9ROoEsQGVn KHwQ==
X-Gm-Message-State: AGi0PuaabBNE/67XqoJa49kuxWKrZWba2XiV7h8vXEiGUUvk858rKsdj PjyfU928cZ+6EZxVp306ciMF7WH/XBY=
X-Google-Smtp-Source: APiQypJxzcmVasW96rrGFq199hiYFJIKrc3LxkGj6Qd3zc8Aobv8giKLpzHs2qrQO6t5smFf1oug1g==
X-Received: by 2002:a5d:938a:: with SMTP id c10mr16435068iol.157.1588894726596;  Thu, 07 May 2020 16:38:46 -0700 (PDT)
Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id a6sm3096819ioe.10.2020.05.07.16.38.45 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 16:38:45 -0700 (PDT)
Received: by mail-il1-f179.google.com with SMTP id s10so4422105iln.11 for ; Thu, 07 May 2020 16:38:45 -0700 (PDT)
X-Received: by 2002:a92:2912:: with SMTP id l18mr17538012ilg.28.1588894725326;  Thu, 07 May 2020 16:38:45 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Thu, 7 May 2020 16:38:34 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dick Hardt 
Cc: OAuth WG , Torsten Lodderstedt ,  Mike Jones 
Content-Type: multipart/alternative; boundary="000000000000b0502c05a5176101"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 May 2020 23:38:53 -0000

--000000000000b0502c05a5176101
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Backing up a step or two, there's another point here that I think has been
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients,
and authorization code injection for all clients. We've only been talking
about authorization code injection on the list so far. The quoted section
of the security BCP (4.5.3) which says clients can do PKCE or use the
nonce, is only talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client
requests an ID token. Public clients using the nonce parameter are still
susceptible to stolen authorization codes so they still need to do PKCE as
well.

The only case where OpenID Connect clients don't benefit from PKCE is if
they are also confidential clients. Public client OIDC clients still need
to do PKCE even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from
PKCE because they can then enforce the authorization code injection
protection server-side rather than cross their fingers that clients
implemented the nonce check properly.

I really don't think it's worth the amount of explanation this will take in
the future to write an exception into OAuth 2.1 or the Security BCP for
only some types of OpenID Connect clients when all clients would benefit
from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:

> Hello!
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
> The advantages or requiring PKCE are:
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
> Dick, Aaron, and Torsten
>
> =E1=90=A7
>

--000000000000b0502c05a5176101
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Backing up a step or two, there's ano=
ther point here that I think has been missed in these discussions.

=

PKCE solves two problems: stolen authorization codes for public =
clients, and authorization code injection for all clients. We've only b=
een talking about authorization code injection on the list so far. The quot=
ed section of the security BCP (4.5.3) which says clients can do PKCE or us=
e the nonce, is only talking about preventing authorization code injection.=


The nonce parameter solves authorization code inj=
ection if the client requests an ID token. Public clients using the nonce p=
arameter are still susceptible to stolen authorization codes so they still =
need to do PKCE as well.

The only case where OpenI=
D Connect clients don't benefit from PKCE is if they are also confident=
ial clients. Public client OIDC clients still need to do PKCE even if they =
check the nonce.

OpenID Connect servers working wi=
th confidential clients still benefit from PKCE because they can then enfor=
ce the authorization code injection protection server-side=C2=A0rather=C2=
=A0than cross their fingers that clients implemented the nonce check proper=
ly.

I really don't think it's worth the am=
ount of explanation this will take in the future to write an exception into=
 OAuth 2.1 or the Security BCP for only some types of OpenID Connect client=
s when all clients would benefit from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM D=
ick Hardt <dick.hardt@gmail.com<=
/a>> wrote:
<=
div dir=3D"ltr">
Hello!

We would like to=
 have PKCE be a MUST in OAuth 2.1 code flows. This is best practice for OAu=
th 2.0. It is not common in OpenID Connect servers as the nonce solves some=
 of the issues that PKCE protects against. We think that most OpenID Connec=
t implementations also support OAuth 2.0, and hence=C2=A0have support for P=
KCE if following best practices.

The advantages or=
 requiring PKCE are:

- a simpler programming model=
 across all OAuth applications and profiles as they all use PKCE
=

- reduced attack surface when using=C2=A0 S256 as a fingerpr=
int of the verifier is sent through the browser instead of the clear text v=
alue

- enforcement by AS not client - makes it eas=
ier to handle for client developers and AS can ensure the check is conducte=
d

What are disadvantages besides the potential=
 impact to OpenID Connect deployments? How significant is that impact?

Dick, Aaron, and Torsten

3D""=E1=90=A7




--000000000000b0502c05a5176101--


From nobody Thu May  7 18:42:47 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432133A0AE6 for ; Thu,  7 May 2020 18:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF7qzr9tJ2Li for ; Thu,  7 May 2020 18:42:42 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640123.outbound.protection.outlook.com [40.107.64.123]) (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 E76883A0AE4 for ; Thu,  7 May 2020 18:42:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l1d3pDY4tg2dEPVrPsWxgxUObKNhQpIWaG3W9phuivOITtKDdNDPXC9YraxEjW4bT3hdNgjcH/haKh/DjvgF0Iwu5ulkAxOStG2pj5d3+3oalm1964sRzxyJnLBxDmx591TD0h8HDsyn5n3ZuFdJELCLsP2WU1xuSMy7YklqPbK9aVIzu1Baz2WhWWzUvF2Asa+VqQhK1ebT8uBNwUwsZPUgH81ryR4lU/9UtQmsXlvjaUo9tcNSMuAi+qhgs7f/zhuCC/5MRMzoE/CUCFJ1ioUjhW7x6oRVTHOqXxrBEXAEEVo6kTEEKvKybRgcCUlb0+8iiufq/qBnWzBTO5f1DQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=btKIvsxbkipySqW+k+HhSUCtxuWv4at9MvU3OBqM3fA=; b=hW2vkuIjzmrGw0mRKtrD2TbQHYKo7A70+N0TYNoRdugVGD0fWfmus49xwgcpsiJ4Fohq8spAvH37vv+0quGeyYeyR5puQrc6yvjnyxXf4K2hzl0VZlnuBR83KcUpokGwCxCz2SeM2ZV+58rwJKmX2oZXO+FEyyz8fN73H93UAvvQL/K5Ck5Vr1K2WoOmAAAjYDituQ2tqOwT8B7m1iTRI8af0EdJyi41xsGAx4hUSCuysOrXaLApIT2FPFPZT2ndZ/VxOhdq5mk6osSZxQKvXAavA9nhUj4zjXMOO0RbzB2Wx58qS5BM949N+iwG2I1rz0Gy1MI0wxwU2KACC0uu8Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=btKIvsxbkipySqW+k+HhSUCtxuWv4at9MvU3OBqM3fA=; b=PLnDV+35707BWnztou1vvdUqaO/nhxMRXtxR5OzAA1KZwiEYFFUHBwV9kgQN7HZo1mjb3GU87F+4sVw28BOmApeno9h3qpBnD/LwBW69DxhfqIc8M9QTWTxqsxlgd1aaY7ro5rM3Z27pIpIEVPcdoQIOO2nYmrQO2wWh9+f9/Sk=
Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BY5PR00MB0808.namprd00.prod.outlook.com (2603:10b6:a03:1c6::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3010.0; Fri, 8 May 2020 01:42:34 +0000
Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::7d21:c7e9:3141:cf8d]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::7d21:c7e9:3141:cf8d%9]) with mapi id 15.20.3020.000; Fri, 8 May 2020 01:42:34 +0000
From: Mike Jones 
To: Aaron Parecki , Dick Hardt 
CC: OAuth WG , Torsten Lodderstedt 
Thread-Topic: OAuth 2.1 - require PKCE?
Thread-Index: AdYk2e3isCGyBFqJR6KJhTwCOhG/oA==
Date: Fri, 8 May 2020 01:42:34 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e6bd1af8-cf02-4b28-bba9-00002cff9155; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-08T01:07:28Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d5d18573-5490-4c72-7ecb-08d7f2f114ee
x-ms-traffictypediagnostic: BY5PR00MB0808:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:4941;
x-forefront-prvs: 039735BC4E
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7Vrzw5H6N5nFcAKqd3Qa1M2UiAe2tQaqDWlC5arsMhHKC7AkWwOUbALp4evTh3q6iFn0c1ttmFKAdqchDZlP0mwOAusifAr345rvqxt6kxW++PCFOvUEO5Hf1aQNhveFBLG/gy++2fe4JBsW/h/BCn35uwCcZd+2m/XT3PF2vwV3ogY2h4o27c6zoWFGDh8hCWuuwlqux/eUc3QFtZQNa6RaEQgGR0WMpnG3Ti90tvQ009PzaYofKn7NoZtRfZjbHk6cm3drIpxKANf+Gc+Ec/rogUTv2+2NaDi7CiaeHZCH1KYE6BkeiGQgE+o3+v0Rhls3pwjUtp9Q03LXVd9bRONUJe9Lrw6DgsUbFeMNHBa1mhT6VrWgtcA+kvzja2BAwYEXTgXgaDjQcVBGz1aC5ccp/DkI/gpi1c+sNWPuUcsdpS+imkhm+8LPNB5aMuMR
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY5PR00MB0676.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(366004)(376002)(346002)(39860400002)(136003)(396003)(33430700001)(5660300002)(478600001)(9686003)(4326008)(55016002)(86362001)(66574014)(33656002)(2906002)(8990500004)(54906003)(26005)(53546011)(110136005)(64756008)(7696005)(6506007)(10290500003)(186003)(316002)(66946007)(83320400001)(83280400001)(83310400001)(83290400001)(83300400001)(33440700001)(8676002)(66556008)(76236002)(76116006)(8936002)(66446008)(82950400001)(66476007)(71200400001)(82960400001)(52536014)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: teCzTAJundwRVL7LBjEQnFjnObnGDC8okt2hsHpwiDmODVF3RUUVuGKuUg/rMBTd1SX0umAuyfkjj2o0IREAvvbFvU7TwlQ0804nWLyL8wS/5otNv5PQ2OD/fYAeKrriuWd5vjlT+v6NKnDhuuB/tGmTK+W51f8Z1T5hhPtSsr6EHpvrBIrdmHtOq9n6eZZDK3rfyU4gYYStn3U4mQeS5Z3P7SH3gIfN5goIhh/zW7IIlmEiYhQI4ZUTDsit+0vRBEw7Oalfg+s3B4yAhPlRwKOsply+6dXW9yGo7cLaC547H7YNRScaXFMo5rovyIMc8mld0TiICN4Hj0jsBGOqw5Vg4I4kl1dbMtNfOdAWwsPJ5FXKpzpvcNO7IboFHB5DTXZAs2U9/aKFoYJCrLIwaYpu+3kEpqL/5L2/yPEB3hK8Q+q2N220fhr7luHs7YKolaSiQiF5BzxS5wjbC1DRgzTJCK00tfeNpK5jaoZffOOJhohqXpagfR2opBaOP2uQuNqCJ+FZorKX7sIKcGN1/vMQuTeXt1jZv5ZkHz68GiEuVUVasYthb8vUGoGnMU48Hkm47+BbK9Nz4WMw189DkaFFu5/UVI0SWWUcJP4zdfmBDJGOK+JKLnfiw6IqFry1J5i3xCoGrX1AUCWEvriI7Nm6mgGYtGc3vETvC4zi8aIC3wLtFh+WuDANTFXzhOx0wYQRP7eE3Za9jrkibQpJ92e9lLND8cnWnwwDy/RrFmu2paBuBiQVt7t0687tZE21sRR+lBkvMDAl7NdCJNe3i40dl+3VtH9egf6N1sNaaWI=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR00MB06766F71775C01E586CD1C12F5A20BY5PR00MB0676namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0676.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d5d18573-5490-4c72-7ecb-08d7f2f114ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 01:42:34.6597 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VX8xaqc7HpqZ+D2gUBxX21fiYHDd5GuT0wbIdnMVyyAOlnFB3rFSLwl4BGYVcIOkiGv6nyYZBGV0OBU0If8yXg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0808
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 01:42:46 -0000

--_000_BY5PR00MB06766F71775C01E586CD1C12F5A20BY5PR00MB0676namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWFyb24sIEkgYmVsaWV2ZSB5b3XigJlyZSB0cnlpbmcgdG8gb3B0aW1pemUgdGhlIHdyb25nIHRo
aW5nLiAgWW914oCZcmUgY29uY2VybmVkIGFib3V0IOKAnHRoZSBhbW91bnQgb2YgZXhwbGFuYXRp
b24gdGhpcyB3aWxsIHRha2XigJ0uICBUaGF04oCZcyBvcHRpbWl6aW5nIGZvciBzcGVjIHNpbXBs
aWNpdHkg4oCTIGEgZ29hbCB0aGF0IEkgZG8gdW5kZXJzdGFuZC4gIEhvd2V2ZXIsIGJ5IHdyaXRp
bmcgdGhlc2UgZmV3IHNlbnRlbmNlcyBvciBwYXJhZ3JhcGhzLCB3ZeKAmWxsIG1ha2UgaXQgY2xl
YXIgdG8gZGV2ZWxvcGVycyB0aGF0IGh1bmRyZWRzIG9yIHRob3VzYW5kcyBvZiBkZXBsb3llZCBP
cGVuSUQgQ29ubmVjdCBSUHMgd29u4oCZdCBoYXZlIHRvIGNoYW5nZSB0aGVpciBkZXBsb3ltZW50
cy4gIFRoYXTigJlzIG9wdGltaXppbmcgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIG1pbmltaXpp
bmcgdGhlIGJ1cmRlbiBvbiBkZXZlbG9wZXJzLCB3aGljaCBhcmUgZmFyIG1vcmUgaW1wb3J0YW50
Lg0KDQpBcyBCcmlhbiBDYW1wYmVsbCB3cm90ZSwg4oCcVGhleSBhcmUgbm90IGVxdWl2YWxlbnQg
YW5kIGhhdmUgdmVyeSBkaWZmZXJlbnQgcmFtaWZpY2F0aW9ucyBvbiBpbnRlcm9wZXJhYmlsaXR5
4oCdLg0KDQpFdmVuIGlmIHlvdeKAmXJlIG9wdGltaXppbmcgZm9yIHdyaXRpbmcsIHRha2luZyBh
IG1pbmltYWxseSBpbnZhc2l2ZSBwcm90b2NvbCBjaGFuZ2UgYXBwcm9hY2ggd2lsbCBvcHRpbWl6
ZSB0aGF0LCBvdmVyYWxsLiAgSWYgd2UgcHJvY2VlZCBhcyB5b3XigJlyZSBzdWdnZXN0aW5nLCBh
IGh1Z2UgYW1vdW50IG9mIHdyaXRpbmcgd2lsbCBvY2N1ciBvbiBTdGFja092ZXJmbG93LCBNZWRp
dW0sIFNsYXNoRG90LCBibG9ncywgYW5kIG90aGVyIGRldmVsb3BlciBmb3J1bXMsIHdoZXJlIGNv
bmZ1c2VkIGRldmVsb3BlcnMgd2lsbCBhc2sg4oCcV2h5IGRvIEkgaGF2ZSB0byBjaGFuZ2UgbXkg
ZGVwbG95ZWQgY29kZT/igJ0gd2l0aCB0aGUgYW5zd2VycyBiZWluZyDigJxEZXNwaXRlIHdoYXQg
dGhlIDIuMSBzcGVjIHNheXMsIHRoZXJl4oCZcyBubyBuZWVkIHRvIGNoYW5nZSB5b3VyIGRlcGxv
eWVkIGNvZGUu4oCdDQoNCknigJlkIGdsYWRseSB3cml0ZSBhIGZldyBzZW50ZW5jZXMgaW4gb3Vy
IG5ldyBzcGVjcyBub3cgdG8gcHJldmVudCBvbmdvaW5nIGNvbmZ1c2lvbiBhbmQgaW50ZXJvcCBw
cm9ibGVtcyB0aGF0IHdvdWxkIG90aGVyd2lzZSByZXN1bHQuICBMZXQgbWUga25vdyB3aGVuIHlv
deKAmXJlIHJlYWR5IHRvIGluY29ycG9yYXRlIHRoZW0gaW50byB0aGUgc3BlYyB0ZXh0Lg0KDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0g
TWlrZQ0KDQpGcm9tOiBBYXJvbiBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT4NClNlbnQ6IFRo
dXJzZGF5LCBNYXkgNywgMjAyMCA0OjM5IFBNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBn
bWFpbC5jb20+DQpDYzogT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPjsgVG9yc3RlbiBMb2RkZXJz
dGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSZTogT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPw0K
DQpCYWNraW5nIHVwIGEgc3RlcCBvciB0d28sIHRoZXJlJ3MgYW5vdGhlciBwb2ludCBoZXJlIHRo
YXQgSSB0aGluayBoYXMgYmVlbiBtaXNzZWQgaW4gdGhlc2UgZGlzY3Vzc2lvbnMuDQoNClBLQ0Ug
c29sdmVzIHR3byBwcm9ibGVtczogc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgZm9yIHB1Ymxp
YyBjbGllbnRzLCBhbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBmb3IgYWxsIGNsaWVu
dHMuIFdlJ3ZlIG9ubHkgYmVlbiB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRpb24gY29kZSBpbmpl
Y3Rpb24gb24gdGhlIGxpc3Qgc28gZmFyLiBUaGUgcXVvdGVkIHNlY3Rpb24gb2YgdGhlIHNlY3Vy
aXR5IEJDUCAoNC41LjMpIHdoaWNoIHNheXMgY2xpZW50cyBjYW4gZG8gUEtDRSBvciB1c2UgdGhl
IG5vbmNlLCBpcyBvbmx5IHRhbGtpbmcgYWJvdXQgcHJldmVudGluZyBhdXRob3JpemF0aW9uIGNv
ZGUgaW5qZWN0aW9uLg0KDQpUaGUgbm9uY2UgcGFyYW1ldGVyIHNvbHZlcyBhdXRob3JpemF0aW9u
IGNvZGUgaW5qZWN0aW9uIGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gSUQgdG9rZW4uIFB1Ymxp
YyBjbGllbnRzIHVzaW5nIHRoZSBub25jZSBwYXJhbWV0ZXIgYXJlIHN0aWxsIHN1c2NlcHRpYmxl
IHRvIHN0b2xlbiBhdXRob3JpemF0aW9uIGNvZGVzIHNvIHRoZXkgc3RpbGwgbmVlZCB0byBkbyBQ
S0NFIGFzIHdlbGwuDQoNClRoZSBvbmx5IGNhc2Ugd2hlcmUgT3BlbklEIENvbm5lY3QgY2xpZW50
cyBkb24ndCBiZW5lZml0IGZyb20gUEtDRSBpcyBpZiB0aGV5IGFyZSBhbHNvIGNvbmZpZGVudGlh
bCBjbGllbnRzLiBQdWJsaWMgY2xpZW50IE9JREMgY2xpZW50cyBzdGlsbCBuZWVkIHRvIGRvIFBL
Q0UgZXZlbiBpZiB0aGV5IGNoZWNrIHRoZSBub25jZS4NCg0KT3BlbklEIENvbm5lY3Qgc2VydmVy
cyB3b3JraW5nIHdpdGggY29uZmlkZW50aWFsIGNsaWVudHMgc3RpbGwgYmVuZWZpdCBmcm9tIFBL
Q0UgYmVjYXVzZSB0aGV5IGNhbiB0aGVuIGVuZm9yY2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBp
bmplY3Rpb24gcHJvdGVjdGlvbiBzZXJ2ZXItc2lkZSByYXRoZXIgdGhhbiBjcm9zcyB0aGVpciBm
aW5nZXJzIHRoYXQgY2xpZW50cyBpbXBsZW1lbnRlZCB0aGUgbm9uY2UgY2hlY2sgcHJvcGVybHku
DQoNCkkgcmVhbGx5IGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdGhlIGFtb3VudCBvZiBleHBsYW5h
dGlvbiB0aGlzIHdpbGwgdGFrZSBpbiB0aGUgZnV0dXJlIHRvIHdyaXRlIGFuIGV4Y2VwdGlvbiBp
bnRvIE9BdXRoIDIuMSBvciB0aGUgU2VjdXJpdHkgQkNQIGZvciBvbmx5IHNvbWUgdHlwZXMgb2Yg
T3BlbklEIENvbm5lY3QgY2xpZW50cyB3aGVuIGFsbCBjbGllbnRzIHdvdWxkIGJlbmVmaXQgZnJv
bSBQS0NFIGFueXdheS4NCg0KQWFyb24NCg0KDQoNCk9uIFdlZCwgTWF5IDYsIDIwMjAgYXQgMTA6
NDggQU0gRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRA
Z21haWwuY29tPj4gd3JvdGU6DQpIZWxsbyENCg0KV2Ugd291bGQgbGlrZSB0byBoYXZlIFBLQ0Ug
YmUgYSBNVVNUIGluIE9BdXRoIDIuMSBjb2RlIGZsb3dzLiBUaGlzIGlzIGJlc3QgcHJhY3RpY2Ug
Zm9yIE9BdXRoIDIuMC4gSXQgaXMgbm90IGNvbW1vbiBpbiBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJz
IGFzIHRoZSBub25jZSBzb2x2ZXMgc29tZSBvZiB0aGUgaXNzdWVzIHRoYXQgUEtDRSBwcm90ZWN0
cyBhZ2FpbnN0LiBXZSB0aGluayB0aGF0IG1vc3QgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRp
b25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBoZW5jZSBoYXZlIHN1cHBvcnQgZm9yIFBL
Q0UgaWYgZm9sbG93aW5nIGJlc3QgcHJhY3RpY2VzLg0KDQpUaGUgYWR2YW50YWdlcyBvciByZXF1
aXJpbmcgUEtDRSBhcmU6DQoNCi0gYSBzaW1wbGVyIHByb2dyYW1taW5nIG1vZGVsIGFjcm9zcyBh
bGwgT0F1dGggYXBwbGljYXRpb25zIGFuZCBwcm9maWxlcyBhcyB0aGV5IGFsbCB1c2UgUEtDRQ0K
DQotIHJlZHVjZWQgYXR0YWNrIHN1cmZhY2Ugd2hlbiB1c2luZyAgUzI1NiBhcyBhIGZpbmdlcnBy
aW50IG9mIHRoZSB2ZXJpZmllciBpcyBzZW50IHRocm91Z2ggdGhlIGJyb3dzZXIgaW5zdGVhZCBv
ZiB0aGUgY2xlYXIgdGV4dCB2YWx1ZQ0KDQotIGVuZm9yY2VtZW50IGJ5IEFTIG5vdCBjbGllbnQg
LSBtYWtlcyBpdCBlYXNpZXIgdG8gaGFuZGxlIGZvciBjbGllbnQgZGV2ZWxvcGVycyBhbmQgQVMg
Y2FuIGVuc3VyZSB0aGUgY2hlY2sgaXMgY29uZHVjdGVkDQoNCldoYXQgYXJlIGRpc2FkdmFudGFn
ZXMgYmVzaWRlcyB0aGUgcG90ZW50aWFsIGltcGFjdCB0byBPcGVuSUQgQ29ubmVjdCBkZXBsb3lt
ZW50cz8gSG93IHNpZ25pZmljYW50IGlzIHRoYXQgaW1wYWN0Pw0KDQpEaWNrLCBBYXJvbiwgYW5k
IFRvcnN0ZW4NCg0K4ZCnDQo=

--_000_BY5PR00MB06766F71775C01E586CD1C12F5A20BY5PR00MB0676namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
QWFyb24sIEkgYmVsaWV2ZSB5b3XigJlyZSB0cnlpbmcgdG8gb3B0aW1pemUgdGhlIHdyb25nIHRo
aW5nLiZuYnNwOyBZb3XigJlyZSBjb25jZXJuZWQgYWJvdXQg4oCcPC9zcGFuPnRoZSBhbW91bnQg
b2YgZXhwbGFuYXRpb24gdGhpcyB3aWxsIHRha2U8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
4oCdLiZuYnNwOyBUaGF04oCZcyBvcHRpbWl6aW5nIGZvciBzcGVjIHNpbXBsaWNpdHkg4oCTIGEg
Z29hbA0KIHRoYXQgSSBkbyB1bmRlcnN0YW5kLiZuYnNwOyBIb3dldmVyLCBieSB3cml0aW5nIHRo
ZXNlIGZldyBzZW50ZW5jZXMgb3IgcGFyYWdyYXBocywgd2XigJlsbCBtYWtlIGl0IGNsZWFyIHRv
IGRldmVsb3BlcnMgdGhhdCBodW5kcmVkcyBvciB0aG91c2FuZHMgb2YgZGVwbG95ZWQgT3BlbklE
IENvbm5lY3QgUlBzIHdvbuKAmXQgaGF2ZSB0byBjaGFuZ2UgdGhlaXIgZGVwbG95bWVudHMuJm5i
c3A7IFRoYXTigJlzIG9wdGltaXppbmcgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIG1pbmltaXpp
bmcNCiB0aGUgYnVyZGVuIG9uIGRldmVsb3BlcnMsIHdoaWNoIGFyZSBmYXIgbW9yZSBpbXBvcnRh
bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BcyBCcmlhbiBDYW1wYmVs
bCB3cm90ZSwg4oCcPC9zcGFuPlRoZXkgYXJlIG5vdCBlcXVpdmFsZW50IGFuZCBoYXZlIHZlcnkg
ZGlmZmVyZW50IHJhbWlmaWNhdGlvbnMgb24gaW50ZXJvcGVyYWJpbGl0eTxzcGFuIHN0eWxlPSJj
b2xvcjojMDAyMDYwIj7igJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5F
dmVuIGlmIHlvdeKAmXJlIG9wdGltaXppbmcgZm9yIHdyaXRpbmcsIHRha2luZyBhIG1pbmltYWxs
eSBpbnZhc2l2ZSBwcm90b2NvbCBjaGFuZ2UgYXBwcm9hY2ggd2lsbCBvcHRpbWl6ZSB0aGF0LCBv
dmVyYWxsLiZuYnNwOyBJZiB3ZSBwcm9jZWVkIGFzIHlvdeKAmXJlIHN1Z2dlc3RpbmcsIGEgaHVn
ZSBhbW91bnQgb2Ygd3JpdGluZyB3aWxsIG9jY3VyIG9uIFN0YWNrT3ZlcmZsb3csDQogTWVkaXVt
LCBTbGFzaERvdCwgYmxvZ3MsIGFuZCBvdGhlciBkZXZlbG9wZXIgZm9ydW1zLCB3aGVyZSBjb25m
dXNlZCBkZXZlbG9wZXJzIHdpbGwgYXNrIOKAnFdoeSBkbyBJIGhhdmUgdG8gY2hhbmdlIG15IGRl
cGxveWVkIGNvZGU/4oCdIHdpdGggdGhlIGFuc3dlcnMgYmVpbmcg4oCcRGVzcGl0ZSB3aGF0IHRo
ZSAyLjEgc3BlYyBzYXlzLCB0aGVyZeKAmXMgbm8gbmVlZCB0byBjaGFuZ2UgeW91ciBkZXBsb3ll
ZCBjb2RlLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SeKAmWQgZ2xh
ZGx5IHdyaXRlIGEgZmV3IHNlbnRlbmNlcyBpbiBvdXIgbmV3IHNwZWNzIG5vdyB0byBwcmV2ZW50
IG9uZ29pbmcgY29uZnVzaW9uIGFuZCBpbnRlcm9wIHByb2JsZW1zIHRoYXQgd291bGQgb3RoZXJ3
aXNlIHJlc3VsdC4mbmJzcDsgTGV0IG1lIGtub3cgd2hlbiB5b3XigJlyZSByZWFkeSB0byBpbmNv
cnBvcmF0ZSB0aGVtIGludG8gdGhlIHNwZWMgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN
aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBBYXJv
biBQYXJlY2tpICZsdDthYXJvbkBwYXJlY2tpLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFRo
dXJzZGF5LCBNYXkgNywgMjAyMCA0OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0ICZs
dDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHICZsdDtv
YXV0aEBpZXRmLm9yZyZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVy
c3RlZHQubmV0Jmd0OzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFja2luZyB1cCBh
IHN0ZXAgb3IgdHdvLCB0aGVyZSdzIGFub3RoZXIgcG9pbnQgaGVyZSB0aGF0IEkgdGhpbmsgaGFz
IGJlZW4gbWlzc2VkIGluIHRoZXNlIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEtDRSBzb2x2ZXMgdHdvIHByb2JsZW1zOiBzdG9sZW4g
YXV0aG9yaXphdGlvbiBjb2RlcyBmb3IgcHVibGljIGNsaWVudHMsIGFuZCBhdXRob3JpemF0aW9u
IGNvZGUgaW5qZWN0aW9uIGZvciBhbGwgY2xpZW50cy4gV2UndmUgb25seSBiZWVuIHRhbGtpbmcg
YWJvdXQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBvbiB0aGUgbGlzdCBzbyBmYXIuIFRo
ZSBxdW90ZWQgc2VjdGlvbiBvZiB0aGUgc2VjdXJpdHkNCiBCQ1AgKDQuNS4zKSB3aGljaCBzYXlz
IGNsaWVudHMgY2FuIGRvIFBLQ0Ugb3IgdXNlIHRoZSBub25jZSwgaXMgb25seSB0YWxraW5nIGFi
b3V0IHByZXZlbnRpbmcgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5vbmNlIHBhcmFt
ZXRlciBzb2x2ZXMgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBpZiB0aGUgY2xpZW50IHJl
cXVlc3RzIGFuIElEIHRva2VuLiBQdWJsaWMgY2xpZW50cyB1c2luZyB0aGUgbm9uY2UgcGFyYW1l
dGVyIGFyZSBzdGlsbCBzdXNjZXB0aWJsZSB0byBzdG9sZW4gYXV0aG9yaXphdGlvbiBjb2RlcyBz
byB0aGV5IHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb25seSBjYXNlIHdoZXJlIE9w
ZW5JRCBDb25uZWN0IGNsaWVudHMgZG9uJ3QgYmVuZWZpdCBmcm9tIFBLQ0UgaXMgaWYgdGhleSBh
cmUgYWxzbyBjb25maWRlbnRpYWwgY2xpZW50cy4gUHVibGljIGNsaWVudCBPSURDIGNsaWVudHMg
c3RpbGwgbmVlZCB0byBkbyBQS0NFIGV2ZW4gaWYgdGhleSBjaGVjayB0aGUgbm9uY2UuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9wZW5JRCBD
b25uZWN0IHNlcnZlcnMgd29ya2luZyB3aXRoIGNvbmZpZGVudGlhbCBjbGllbnRzIHN0aWxsIGJl
bmVmaXQgZnJvbSBQS0NFIGJlY2F1c2UgdGhleSBjYW4gdGhlbiBlbmZvcmNlIHRoZSBhdXRob3Jp
emF0aW9uIGNvZGUgaW5qZWN0aW9uIHByb3RlY3Rpb24gc2VydmVyLXNpZGUmbmJzcDtyYXRoZXIm
bmJzcDt0aGFuIGNyb3NzIHRoZWlyIGZpbmdlcnMgdGhhdCBjbGllbnRzIGltcGxlbWVudGVkIHRo
ZSBub25jZSBjaGVjaw0KIHByb3Blcmx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlYWxseSBkb24ndCB0aGluayBpdCdzIHdvcnRoIHRo
ZSBhbW91bnQgb2YgZXhwbGFuYXRpb24gdGhpcyB3aWxsIHRha2UgaW4gdGhlIGZ1dHVyZSB0byB3
cml0ZSBhbiBleGNlcHRpb24gaW50byBPQXV0aCAyLjEgb3IgdGhlIFNlY3VyaXR5IEJDUCBmb3Ig
b25seSBzb21lIHR5cGVzIG9mIE9wZW5JRCBDb25uZWN0IGNsaWVudHMgd2hlbiBhbGwgY2xpZW50
cyB3b3VsZCBiZW5lZml0IGZyb20gUEtDRSBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1heSA2LCAyMDIw
IGF0IDEwOjQ4IEFNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdt
YWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SGVsbG8hPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X
ZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUgZmxv
d3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29tbW9u
IGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9mIHRo
ZSBpc3N1ZXMgdGhhdCBQS0NFIHByb3RlY3RzIGFnYWluc3QuIFdlIHRoaW5rIHRoYXQgbW9zdCBP
cGVuSUQgQ29ubmVjdA0KIGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1dGggMi4wLCBh
bmQgaGVuY2UmbmJzcDtoYXZlIHN1cHBvcnQgZm9yIFBLQ0UgaWYgZm9sbG93aW5nIGJlc3QgcHJh
Y3RpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGUgYWR2YW50YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gYSBzaW1wbGVyIHByb2dy
YW1taW5nIG1vZGVsIGFjcm9zcyBhbGwgT0F1dGggYXBwbGljYXRpb25zIGFuZCBwcm9maWxlcyBh
cyB0aGV5IGFsbCB1c2UgUEtDRTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4tIHJlZHVjZWQgYXR0YWNrIHN1cmZhY2Ugd2hlbiB1c2luZyZuYnNw
OyBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlmaWVyIGlzIHNlbnQgdGhyb3VnaCB0
aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZhbHVlPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gZW5mb3JjZW1lbnQgYnkg
QVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUgZm9yIGNsaWVudCBkZXZl
bG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25kdWN0ZWQ8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBhcmUgZGlz
YWR2YW50YWdlcyBiZXNpZGVzIHRoZSBwb3RlbnRpYWwgaW1wYWN0IHRvIE9wZW5JRCBDb25uZWN0
IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlmaWNhbnQgaXMgdGhhdCBpbXBhY3Q/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpY2ssIEFhcm9uLCBh
bmQgVG9yc3RlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9
IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hlaWdodDouMDEwNGluIiBpZD0iX3gwMDAwX2kxMDI1
IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9Z
WEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTQ1MjQz
OGJhLWQ0MjktNDY1Ni1hY2U5LWIyODQ3NDRiYzE3MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3
LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0
ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BY5PR00MB06766F71775C01E586CD1C12F5A20BY5PR00MB0676namp_--


From nobody Thu May  7 19:29:27 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07D63A0C16 for ; Thu,  7 May 2020 19:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LygCwkw70kcW for ; Thu,  7 May 2020 19:29:19 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261963A00D4 for ; Thu,  7 May 2020 19:29:18 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id m24so179681vsq.10 for ; Thu, 07 May 2020 19:29:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0aVNoNhm5yNsSSSKH3L+xZNw3Fme3uBVwKXYtz31nrI=; b=TZ6jf41KcDu+zhf1PdSpljP72lRaRpDjfj8LFMA4iU1s1axGIzu7KUdPuXofwOwqqQ ZKz1btFiTneJ9YT2Bs+0QDA8KWI/iN2DO+yiJuozkUssbO/hO15vCn6fl6xHjzk8tqEq h3bjX/EGg9R57xrmUi8a+AD59JIq+onprYTto=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0aVNoNhm5yNsSSSKH3L+xZNw3Fme3uBVwKXYtz31nrI=; b=DC4x7srlM+FESZEhviT1eUq2EPKlvJuybVGDuxGm1aQtUnwwLyOc/TlJ5hr8kNxyaV XpoAar04Nny1MaOLHXj+sBA2waO1bujb2Vnpj4zipAAGAl7hNZgNBR9GXEfijYvhcg/P 7ou+9lwyz+ZjOkArPBxU/HPL8mlvP1sV0Aq/gElRZYvWg0+xLmea4SqDh6yQo3EeBjW+ Ijw1sPvAdKlHnfdYLnIW7TMJmXNmye83m/epTp0AsG5+DV4lfAXFg/fwhMR3u+WT0uMM HrZEaVDeANUZusPXFkdG4yzk59nui237rQvOyIw3diQd7a8NlCk1vpa5y52xa/A+AgMM MZbA==
X-Gm-Message-State: AGi0PuaINFbAkWv9/6BBXBXelPRuEkGv3ocliMxTA8fvIxP8U++2ZJGp FF/0I7HIy5z4SqB7JcBtsotmYOPLtjVVv/Db/YB0hg==
X-Google-Smtp-Source: APiQypKqsvsdjWdKpC+2UGqwEf6N+TsxMb8BmESsNmQWt1pLSFU+08nq7mqf+OaIoaHz8BfulPOFq2axrd80eYxgs3w=
X-Received: by 2002:a67:7f89:: with SMTP id a131mr242405vsd.184.1588904957762;  Thu, 07 May 2020 19:29:17 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Prabath Siriwardena 
Date: Thu, 7 May 2020 19:29:08 -0700
Message-ID: 
To: Vittorio Bertocci 
Cc: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="00000000000096f47505a519c3c8"
Archived-At: 
Subject: Re: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 02:29:25 -0000

--00000000000096f47505a519c3c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Vittorio for your thoughts!


On Thu, May 7, 2020 at 1:29 PM Vittorio Bertocci  wrote:

> Hi Prabath,
>
> Thanks for your comment! Here are my thoughts.
>
> I don=E2=80=99t believe embedding the state in the AT would help. The sta=
te is
> generated (hence verified, if used for protection) by the client, but the
> content of the AT is really meant for the RS, which has no direct knowled=
ge
> of what the state value should be, not in the first nor all the subsequen=
t
> uses of the AT within its validity period. Also, the client itself is
> forbidden to inspect the content of the access token- you can find the
> details behind that in recent discussions on the list.
>
> I=E2=80=99ll add to this that the implicit grant is on its way out of the=
 grants
> stage, hence doing major changes to accommodate its quirks wouldn=E2=80=
=99t give a
> lot of ROI.
>
> HTH
>
> Thanks!
>
> V.
>
>
>
> *From: *OAuth  on behalf of Prabath Siriwardena
> 
> *Date: *Thursday, May 7, 2020 at 11:56
> *To: *Rifaat Shekh-Yusef , oauth 
> *Subject: *[OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding
> state into the JWT
>
>
>
> Hi all,
>
>
>
> Can we say in [1], that the AS should add the value of *state* parameter
> from the authorization request (if present), to the JWT access token it
> generates?
>
>
>
> This will help to address token injection issue [2], with respect to the
> implicit grant type.
>
>
>
> Appreciate your thoughts on this.
>
>
>
> [1]: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>
> [2]:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4=
.6
>
>
>
> Thanks
>
> -Prabath
>
>
>
> On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef 
> wrote:
>
> Hi all,
>
>
>
> This is a 3rd working group last call for "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>
>
>
> Please send your comments to the OAuth mailing list by May 12, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--00000000000096f47505a519c3c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Vittorio for your thoughts!


On Thu, May 7, 2020 at 1:29 PM Vittorio Bertocci <vittorio.bertocci=3D=
40auth0.com@dmarc.ietf.org> wrote:











Hi Prabath,


Thanks for your comment! Here are my thoughts.


I don=E2=80=99t believe embedding the state in the A=
T would help. The state is generated (hence verified, if used for protectio=
n) by the client, but the content of the AT is really meant for the RS, whi=
ch has no direct knowledge of what the state
 value should be, not in the first nor all the subsequent uses of the AT wi=
thin its validity period. Also, the client itself is forbidden to inspect t=
he content of the access token- you can find the details behind that in rec=
ent discussions on the list.


I=E2=80=99ll add to this that the implicit grant is =
on its way out of the grants stage, hence doing major changes to accommodat=
e its quirks wouldn=E2=80=99t give a lot of ROI.


HTH


Thanks!


V.


=C2=A0




From: =
OAuth <oauth-bounces@ietf.org=
> on behalf of Prabath Siriwardena <prabath=3D40wso2.com@dmarc.ietf.org>
Date: Thursday, May 7, 2020 at 11:56

To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, oauth <oauth@ietf.org>

Subject: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding=
 state into the JWT






=C2=A0








Hi all,






=C2=A0






Can we say in [1], that the AS should add the value =
of state parameter from the authorization request (if present), to t=
he JWT access token it generates?






=C2=A0






This will help to address token injection issue [2],=
 with respect to the implicit grant type.






=C2=A0






Appreciate your thoughts on this.






=C2=A0








=C2=A0






Thanks






-Prabath




=C2=A0






On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef &=
lt;rifaat.ietf@g=
mail.com> wrote:








Hi all,<=
/p>

=C2=A0

This is a 3rd working =
group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access=
 Tokens".


=C2=A0

Here is the document:<=
u>


ht=
tps://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07=C2=A0=C2=
=A0


=C2=A0

Please send your comme=
nts to the OAuth mailing list by May 12, 2020.


=C2=A0

Regards,=



=C2=A0Rifaat & Han=
nes




_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth















--00000000000096f47505a519c3c8--


From nobody Thu May  7 22:36:26 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3405B3A053F for ; Thu,  7 May 2020 22:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=HGFPVSji; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CeGq1uts
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvWviF7B7uHm for ; Thu,  7 May 2020 22:36:20 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688D83A0544 for ; Thu,  7 May 2020 22:36:20 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 2789B1BD; Fri,  8 May 2020 01:36:19 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 08 May 2020 01:36:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=yqCrMUsCxUVd+fdtbSIhqn8nRhRO6xuTAz/rjI1Y19E=; b=HGFPVSjiSw/o KJeTExZXdgCCbiYvzoGCrxx7EUFdXjlGUM4mITjsmpZ0rRvI/sQKtmtfl/ddR5bT I/JHqJFMOnqR3udceZZGBQxTHOT8IbPNb1/tAUIeuZZHf+zokapmLy5mE8UFCU5Q OdtUHYLcHM9HPaY5GGug/ykFbvMJM5r8GWiQI7N+kdEscXfJwVq//6HSEboFyKPJ 7Eg4jDVf/eSgr8YykEKWNgk0XYrBjKvGChVJ0ovtdyC2OnzzPe9SzFQ/acaz3hgB t4AwSwFjJWl0gMPUXOGFMbDgdrJ2aGfZklWLBqyK7uh+p8LWge9i5FD9j94+ehPS EbbTBj4e3w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yqCrMU sCxUVd+fdtbSIhqn8nRhRO6xuTAz/rjI1Y19E=; b=CeGq1utsgHFE+4rBmWSjjM HgJzY5dwy54QdM6ypA4U22SIe2qRJlwmqdGhphLYUYixgTQCGs714NlClgbllyuj Uj+ffbshoHjsYBEwx7AqsIENsYvDWxHdCdXDE/sOgnpgqZfT3bl1IqoEaZxhfGBQ udgq3J/YS5X1IppXuHRL/lBd23IqNJ+JpbaP2xhkgeKIuXDhI1Lm+gCR8AcY32M1 bYadYLrlIg5nybLx/bFtzOZ0GawW0ojCi1bkItSR2UIfv7uB9Q/3s5fPOG08bh1d Jl31hDSaX6q2zvQw2/4h6JUYBJNPL/gIbDeY6VBjhlFYUZRsSHE6RXSgQs4E/Wiw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkedugdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheprfhhihhlihhp phgvucffvgcutfihtghkuceophhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsghsvg gtuhhrihhthidrtghomheqnecuggftrfgrthhtvghrnhepkefggeduudfhleffffeflefh ffdugfevjedtgeejhfeileduvdeileekkedvtdetnecuffhomhgrihhnpehivghtfhdroh hrghenucfkphepkedurdduieegrdduvdelrdelheenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitg ifvggsshgvtghurhhithihrdgtohhm
X-ME-Proxy:    
Received: from philippes-imac.localdomain (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 9145030661E6; Fri,  8 May 2020 01:36:17 -0400 (EDT)
From: Philippe De Ryck 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3757594F-D6B8-44DC-A04C-8EC2CCD86BA6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 8 May 2020 07:36:15 +0200
In-Reply-To: 
Cc: Aaron Parecki , Dick Hardt , OAuth WG 
To: Mike Jones 
References: 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 05:36:24 -0000

--Apple-Mail=_3757594F-D6B8-44DC-A04C-8EC2CCD86BA6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

=46rom working with a lot of developers on understanding OAuth 2.0 and =
OIDC, I definitely vote for simplicity. Understanding the subtle nuances =
of when a nonce is fine and when PKCE should be used is impossible =
without in-depth knowledge of the flows and their properties. =
Misunderstandings will cause security vulnerabilities, which can easily =
be avoided.

Since OAuth 2.1 is a separate spec, I don=E2=80=99t really see a problem =
with existing code not being compliant. They support OAuth 2.0, and if =
they want to be OAuth 2.1 compliant, they add PKCE. If I=E2=80=99m not =
mistaken, other requirements of OAuth 2.1 would also clash with existing =
deployments (e.g., using non-exact redirect URIs).

I believe that optimizing for making OAuth 2.1 easier to understand will =
yield the highest return.

Philippe


> On 8 May 2020, at 03:42, Mike Jones =
 wrote:
>=20
> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  =
You=E2=80=99re concerned about =E2=80=9Cthe amount of explanation this =
will take=E2=80=9D.  That=E2=80=99s optimizing for spec simplicity =E2=80=93=
 a goal that I do understand.  However, by writing these few sentences =
or paragraphs, we=E2=80=99ll make it clear to developers that hundreds =
or thousands of deployed OpenID Connect RPs won=E2=80=99t have to change =
their deployments.  That=E2=80=99s optimizing for interoperability and =
minimizing the burden on developers, which are far more important.
> =20
> As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have =
very different ramifications on interoperability=E2=80=9D.
> =20
> Even if you=E2=80=99re optimizing for writing, taking a minimally =
invasive protocol change approach will optimize that, overall.  If we =
proceed as you=E2=80=99re suggesting, a huge amount of writing will =
occur on StackOverflow, Medium, SlashDot, blogs, and other developer =
forums, where confused developers will ask =E2=80=9CWhy do I have to =
change my deployed code?=E2=80=9D with the answers being =E2=80=9CDespite =
what the 2.1 spec says, there=E2=80=99s no need to change your deployed =
code.=E2=80=9D
> =20
> I=E2=80=99d gladly write a few sentences in our new specs now to =
prevent ongoing confusion and interop problems that would otherwise =
result.  Let me know when you=E2=80=99re ready to incorporate them into =
the spec text.
> =20
>                                                        -- Mike
> =20
> From: Aaron Parecki >=20
> Sent: Thursday, May 7, 2020 4:39 PM
> To: Dick Hardt >
> Cc: OAuth WG >; Torsten =
Lodderstedt >; =
Mike Jones >
> Subject: Re: OAuth 2.1 - require PKCE?
> =20
> Backing up a step or two, there's another point here that I think has =
been missed in these discussions.
> =20
> PKCE solves two problems: stolen authorization codes for public =
clients, and authorization code injection for all clients. We've only =
been talking about authorization code injection on the list so far. The =
quoted section of the security BCP (4.5.3) which says clients can do =
PKCE or use the nonce, is only talking about preventing authorization =
code injection.
> =20
> The nonce parameter solves authorization code injection if the client =
requests an ID token. Public clients using the nonce parameter are still =
susceptible to stolen authorization codes so they still need to do PKCE =
as well.
> =20
> The only case where OpenID Connect clients don't benefit from PKCE is =
if they are also confidential clients. Public client OIDC clients still =
need to do PKCE even if they check the nonce.
> =20
> OpenID Connect servers working with confidential clients still benefit =
from PKCE because they can then enforce the authorization code injection =
protection server-side rather than cross their fingers that clients =
implemented the nonce check properly.
> =20
> I really don't think it's worth the amount of explanation this will =
take in the future to write an exception into OAuth 2.1 or the Security =
BCP for only some types of OpenID Connect clients when all clients would =
benefit from PKCE anyway.
> =20
> Aaron
> =20
> =20
> =20
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt > wrote:
> Hello!
> =20
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is =
best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as the nonce solves some of the issues that PKCE protects against. We =
think that most OpenID Connect implementations also support OAuth 2.0, =
and hence have support for PKCE if following best practices.
> =20
> The advantages or requiring PKCE are:
> =20
> - a simpler programming model across all OAuth applications and =
profiles as they all use PKCE
> =20
> - reduced attack surface when using  S256 as a fingerprint of the =
verifier is sent through the browser instead of the clear text value
> =20
> - enforcement by AS not client - makes it easier to handle for client =
developers and AS can ensure the check is conducted
> =20
> What are disadvantages besides the potential impact to OpenID Connect =
deployments? How significant is that impact?
> =20
> Dick, Aaron, and Torsten
> =20
> =E1=90=A7
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_3757594F-D6B8-44DC-A04C-8EC2CCD86BA6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

=46ro=
m working with a lot of developers on understanding OAuth 2.0 and OIDC, =
I definitely vote for simplicity. Understanding the subtle nuances of =
when a nonce is fine and when PKCE should be used is impossible without =
in-depth knowledge of the flows and their properties. Misunderstandings =
will cause security vulnerabilities, which can easily be avoided.

Since OAuth 2.1 is a =
separate spec, I don=E2=80=99t really see a problem with existing code =
not being compliant. They support OAuth 2.0, and if they want to be =
OAuth 2.1 compliant, they add PKCE. If I=E2=80=99m not mistaken, other =
requirements of OAuth 2.1 would also clash with existing deployments =
(e.g., using non-exact redirect URIs).

I believe that optimizing for making =
OAuth 2.1 easier to understand will yield the highest return.

Philippe




On 8 May 2020, at 03:42, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> =
wrote:

Aaron, I believe you=E2=80=99r=
e trying to optimize the wrong thing.  You=E2=80=99re concerned =
about =E2=80=9Cthe amount of explanation this will take=E2=80=9D.  That=E2=80=99=
s optimizing for spec simplicity =E2=80=93 a goal that I do =
understand.  However, by writing these few sentences or paragraphs, =
we=E2=80=99ll make it clear to developers that hundreds or thousands of =
deployed OpenID Connect RPs won=E2=80=99t have to change their =
deployments.  That=E2=80=99s optimizing for interoperability and =
minimizing the burden on developers, which are far more important.
 
As Brian =
Campbell wrote, =E2=80=9CThey are not equivalent and have very =
different ramifications on interoperability=E2=80=9D.
 
Even if =
you=E2=80=99re optimizing for writing, taking a minimally invasive =
protocol change approach will optimize that, overall.  If we =
proceed as you=E2=80=99re suggesting, a huge amount of writing will =
occur on StackOverflow, Medium, SlashDot, blogs, and other developer =
forums, where confused developers will ask =E2=80=9CWhy do I have to =
change my deployed code?=E2=80=9D with the answers being =E2=80=9CDespite =
what the 2.1 spec says, there=E2=80=99s no need to change your deployed =
code.=E2=80=9D
 
I=E2=80=99d =
gladly write a few sentences in our new specs now to prevent ongoing =
confusion and interop problems that would otherwise result.  Let me =
know when you=E2=80=99re ready to incorporate them into the spec =
text.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: Aaron Parecki <aaron@parecki.com> 
Sent: Thursday, May 7, 2020 4:39 =
PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@ietf.org>; Torsten Lodderstedt =
<torsten@lodderstedt.net>; =
Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: OAuth 2.1 - require =
PKCE?
 
Backing up a step or two, =
there's another point here that I think has been missed in these =
discussions.
 
PKCE solves two problems: stolen authorization codes for =
public clients, and authorization code injection for all clients. We've =
only been talking about authorization code injection on the list so far. =
The quoted section of the security BCP (4.5.3) which says clients can do =
PKCE or use the nonce, is only talking about preventing authorization =
code injection.
 
The nonce parameter solves authorization code injection if =
the client requests an ID token. Public clients using the nonce =
parameter are still susceptible to stolen authorization codes so they =
still need to do PKCE as well.
 
The only case where OpenID Connect clients don't benefit from =
PKCE is if they are also confidential clients. Public client OIDC =
clients still need to do PKCE even if they check the nonce.
 
OpenID Connect servers working with =
confidential clients still benefit from PKCE because they can then =
enforce the authorization code injection protection =
server-side rather than cross their fingers that clients =
implemented the nonce check properly.
 
I really don't think it's worth the =
amount of explanation this will take in the future to write an exception =
into OAuth 2.1 or the Security BCP for only some types of OpenID Connect =
clients when all clients would benefit from PKCE anyway.
 
Aaron
 
 
 
On Wed, May 6, 2020 at =
10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello!
 
We would like to have PKCE be a MUST in OAuth 2.1 code flows. =
This is best practice for OAuth 2.0. It is not common in OpenID Connect =
servers as the nonce solves some of the issues that PKCE protects =
against. We think that most OpenID Connect implementations also support =
OAuth 2.0, and hence have support for PKCE if following best =
practices.
 
The advantages or requiring PKCE are:
 
- a simpler programming model across =
all OAuth applications and profiles as they all use PKCE
 
- reduced attack surface when =
using  S256 as a fingerprint of the verifier is sent through the =
browser instead of the clear text value
 
- enforcement by AS not client - makes =
it easier to handle for client developers and AS can ensure the check is =
conducted
 
What are disadvantages besides the potential impact to OpenID =
Connect deployments? How significant is that impact?
 
Dick, Aaron, and Torsten
 
=E1=90=A7
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_3757594F-D6B8-44DC-A04C-8EC2CCD86BA6--


From nobody Thu May  7 23:50:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD57E3A07EA for ; Thu,  7 May 2020 23:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level: 
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3wNhop1lDiw for ; Thu,  7 May 2020 23:50:20 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317F83A07E9 for ; Thu,  7 May 2020 23:50:20 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 56FB32A9C for ; Fri,  8 May 2020 06:50:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588920617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P0RfDQgkeHis5HlJA3TPPbTCC2IBj7IIfn1/+d6Yzmg=; b=mOCpL2dumBLox7IfaDfwDAuEFismzuMkf3yLH7U80unk/KuAeO/c0s9pZPajh73Y2WDEJU /ftbEbDdVOamnTF624a0A+mKl16rRJ4ME1rbELn5d9ziAMEFpneQAs5uTE8zxDQLH9GCqk vxMzdPE5QbNR5zrhp+Jj4vbByV/g8/I=
To: oauth@ietf.org
References:  
From: Daniel Fett 
Message-ID: <3b016c63-facd-a1cf-cb58-6ad5d8633055@danielfett.de>
Date: Fri, 8 May 2020 08:50:16 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1E952F0315636F5548B44BE2"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1588920617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P0RfDQgkeHis5HlJA3TPPbTCC2IBj7IIfn1/+d6Yzmg=; b=UZ/X04b1y/tlJ/9Dh7JKy+jWPFFLKjv1qIrnk/e7D2wy6pY5dSk/FbR580mVJUeb54usS8 v8/+QdGN2Q037PvaF9V03NxMIxE3rkjDuNh4xklHIiT6Be6GxPlc5pL5KcSn7ti2VRRjh7 b8blNdAhxzjZNMHwJjS+TwIKuGeh8v8=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588920617; a=rsa-sha256; cv=none; b=Ni4FTXzDA2YmEncwo/8ZiCIDxIGE3izoa9OWuP1t0EWXD/xQUEuEyuEo885jGyzjS6i5yZ ylfXsAgR5t0Qck4JMuWqT2gXreX8jX6Q1kRgw0nIvf68S6vN+KDAtM7pxPOb5K4ZXdYFI6 wjI+1mhQmpo7VV7ccLpdmbLJPL3xsQc=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: +
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 06:50:24 -0000

This is a multi-part message in MIME format.
--------------1E952F0315636F5548B44BE2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

+1 to all what Aaron said. Thanks for pointing this out!

We need to address this in the security BCP and this will be a normative
change that affects OpenID Connect Core (just as our current
recommendation on the usage of nonce).

We would then have:

- use PKCE, except if you use OIDC with a nonce, then you don't need
PKCE, except if you are a public client, then you still need PKCE.
- use state, except if you use PKCE, then you don't need state.

I think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases
when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
understanding /why/ you have to do something is key to compliance. The
short version "PKCE protects the code; there is a specific case where it
is not needed, but its better to use it all the time" is easy to
understand. We will not see many implementations following the long
version above correctly.

Second, we dramatically reduce technical complexity by reducing cases
that need to be handled. We reduce correctness and compliance testing
complexity in the same way. We reduce the cost of security analysis,
which scales really badly to more cases.

And finally, using nonce to protect against code injection is less
robust than PKCE. AS have a better track record than clients when it
comes to correctly implementing security mechanisms.

Yes, this will make a number of implementations non-spec-compliant, but
I do not think that this is a huge problem. Software needs to adapt all
the time and a software that has not been changed in a while is probably
not one you would want to use anyway. We are setting a new goal for
implementations to meet and eventually, maintained implementations will
get there.

-Daniel


Am 08.05.20 um 01:38 schrieb Aaron Parecki:
> Backing up a step or two, there's another point here that I think has
> been missed in these discussions.
>
> PKCE solves two problems: stolen authorization codes for public
> clients, and authorization code injection for all clients. We've only
> been talking about authorization code injection on the list so far.
> The quoted section of the security BCP (4.5.3) which says clients can
> do PKCE or use the nonce, is only talking about preventing
> authorization code injection.
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are
> still susceptible to stolen authorization codes so they still need to
> do PKCE as well.
>
> The only case where OpenID Connect clients don't benefit from PKCE is
> if they are also confidential clients. Public client OIDC clients
> still need to do PKCE even if they check the nonce.
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code
> injection protection server-side rather than cross their fingers that
> clients implemented the nonce check properly.
>
> I really don't think it's worth the amount of explanation this will
> take in the future to write an exception into OAuth 2.1 or the
> Security BCP for only some types of OpenID Connect clients when all
> clients would benefit from PKCE anyway.
>
> Aaron
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  > wrote:
>
>     Hello!
>
>     We would like to have PKCE be a MUST in OAuth 2.1 code flows. This
>     is best practice for OAuth 2.0. It is not common in OpenID Connect
>     servers as the nonce solves some of the issues that PKCE protects
>     against. We think that most OpenID Connect implementations also
>     support OAuth 2.0, and hence have support for PKCE if following
>     best practices.
>
>     The advantages or requiring PKCE are:
>
>     - a simpler programming model across all OAuth applications and
>     profiles as they all use PKCE
>
>     - reduced attack surface when using  S256 as a fingerprint of the
>     verifier is sent through the browser instead of the clear text value
>
>     - enforcement by AS not client - makes it easier to handle for
>     client developers and AS can ensure the check is conducted
>
>     What are disadvantages besides the potential impact to OpenID
>     Connect deployments? How significant is that impact?
>
>     Dick, Aaron, and Torsten
>
>     ᐧ
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------1E952F0315636F5548B44BE2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
+1 to all what Aaron said. Thanks for
      pointing this out!

    


    

    
We need to address this in the security
      BCP and this will be a normative change that affects OpenID
      Connect Core (just as our current recommendation on the usage of
      nonce).

    

    


    

    
We would then have:

    


    

    
- use PKCE, except if you use OIDC with
      a nonce, then you don't need PKCE, except if you are a public
      client, then you still need PKCE.

    
- use state, except if you use PKCE,
      then you don't need state.

    


    

    
I think there are very good reasons to
      simplify this down to 

    

    


    

    
- use PKCE

    
- you may or may not use state

    


    

    
First and foremost, not many people
      will understand why there are cases when the BCP/OAuth 2.1 mandate
      PKCE and some where they don't. However, understanding why
      you have to do something is key to compliance. The short version
      "PKCE protects the code; there is a specific case where it is not
      needed, but its better to use it all the time" is easy to
      understand. We will not see many implementations following the
      long version above correctly.

    


    

    
Second, we dramatically reduce
      technical complexity by reducing cases that need to be handled. We
      reduce correctness and compliance testing complexity in the same
      way. We reduce the cost of security analysis, which scales really
      badly to more cases.

    


    

    
And finally, using nonce to protect
      against code injection is less robust than PKCE. AS have a better
      track record than clients when it comes to correctly implementing
      security mechanisms. 

    

    


    

    
Yes, this will make a number of
      implementations non-spec-compliant, but I do not think that this
      is a huge problem. Software needs to adapt all the time and a
      software that has not been changed in a while is probably not one
      you would want to use anyway. We are setting a new goal for
      implementations to meet and eventually, maintained implementations
      will get there.

    

    


    

    
-Daniel

    

    


    

    


    

    
Am 08.05.20 um 01:38 schrieb Aaron
      Parecki:

    

    

      
      

        
Backing up a step or two, there's another point
          here that I think has been missed in these discussions.
          


          

          
PKCE solves two problems: stolen authorization codes for
            public clients, and authorization code injection for all
            clients. We've only been talking about authorization code
            injection on the list so far. The quoted section of the
            security BCP (4.5.3) which says clients can do PKCE or use
            the nonce, is only talking about preventing authorization
            code injection.

          


          

          
The nonce parameter solves authorization code injection
            if the client requests an ID token. Public clients using the
            nonce parameter are still susceptible to stolen
            authorization codes so they still need to do PKCE as well.

          


          

          
The only case where OpenID Connect clients don't benefit
            from PKCE is if they are also confidential clients. Public
            client OIDC clients still need to do PKCE even if they check
            the nonce.

          


          

          
OpenID Connect servers working with confidential clients
            still benefit from PKCE because they can then enforce the
            authorization code injection protection
            server-side rather than cross their fingers that clients
            implemented the nonce check properly.

          


          

          
I really don't think it's worth the amount of explanation
            this will take in the future to write an exception into
            OAuth 2.1 or the Security BCP for only some types of OpenID
            Connect clients when all clients would benefit from PKCE
            anyway.

          


          

          
Aaron

          


          

        

        


        

        

        

          
On Wed, May 6, 2020 at 10:48
            AM Dick Hardt <dick.hardt@gmail.com> wrote:

          

          

            

              
Hello!
                


                

                
We would like to have PKCE be a MUST in OAuth 2.1
                  code flows. This is best practice for OAuth 2.0. It is
                  not common in OpenID Connect servers as the nonce
                  solves some of the issues that PKCE protects against.
                  We think that most OpenID Connect implementations also
                  support OAuth 2.0, and hence have support for PKCE if
                  following best practices.

                


                

                
The advantages or requiring PKCE are:

                


                

                
- a simpler programming model across all OAuth
                  applications and profiles as they all use PKCE

                


                

                
- reduced attack surface when using  S256 as a
                  fingerprint of the verifier is sent through the
                  browser instead of the clear text value

                


                

                
- enforcement by AS not client - makes it easier to
                  handle for client developers and AS can ensure the
                  check is conducted

                

                


                

                
What are disadvantages besides the potential impact
                  to OpenID Connect deployments? How significant is that
                  impact?

                


                

                
Dick, Aaron, and Torsten

                


                

              

            

            
ᐧ

          

        

      

      

      

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


    

    


    

  


--------------1E952F0315636F5548B44BE2--


From nobody Fri May  8 02:23:09 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28E13A093A for ; Fri,  8 May 2020 02:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKf5fnpI7E4u for ; Fri,  8 May 2020 02:23:04 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD703A0938 for ; Fri,  8 May 2020 02:23:02 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d21 with ME id c9Nz220054FMSmm039Nz5R; Fri, 08 May 2020 11:23:00 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 08 May 2020 11:23:00 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org, Daniel Fett 
References: <158608868945.18323.557347538112056951@ietfa.amsl.com> <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr>   <18e38735-ae9f-c41b-0cda-b2818a1038dc@danielfett.de>
From: Denis 
Cc: Vittorio Bertocci 
Message-ID: <7c27543f-6d14-2a5c-8a00-8b7d5baf17b1@free.fr>
Date: Fri, 8 May 2020 11:22:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <18e38735-ae9f-c41b-0cda-b2818a1038dc@danielfett.de>
Content-Type: multipart/alternative; boundary="------------9D0AA13C747E77E0117AD8D5"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 09:23:07 -0000

This is a multi-part message in MIME format.
--------------9D0AA13C747E77E0117AD8D5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Daniel,

Thank you for pointing to your dissertation which has the following 
title : An Expressive Formal Model of the Web Infrastructure.

Since it is 240 pages long (or thick), I have not read everything but 
some sentences brought my attention.

I have experienced formal models in the past and everything depends upon 
the hypothesis that are made upfront.

On page 28:

    1.1.1. The Web Infrastructure Model

    (...)
    Altogether, the model is the *most comprehensive and detailed model
    for the web infrastructure to date* [i.e. in year 2018].
    (...)

On page 40, there is the following sentence:

    *A browser is thought to be used by one honest user*, who is modeled
    as part of the browser.


With such an hypothesis, it is impossible to consider a collusion attack 
between clients, hence the Model omits to consider such a case.
When using a formal approach, it is generally not possible to make sure 
that all attacks have been considered, but when considering
specific attacks, it is possible to demonstrate that they can be 
countered (or not).

Many models are considering "adversaries". This originates from the 
"Alice, Bob and Carol model" where both Alice and Bob
were honest and where Carol was the attacker. In the case of the "Alice 
and Bob Collusion attack", Alice and Bob are good friends.
The target of the attack is a RS. The RS is not an adversary : it does 
nothing bad. Alice and Bob are adversaries towards Carol (the RS).
This can bee seen as the revenge of "Alice and Bob" against Carol.  :-)

On page 29, the text states:

    Model of OAuth 2.0

    Using our generic web model, we build a formal model of OAuth,
    closely following the OAuth 2.0 standard [RFC6749].

On page 72, Figure 3.1 there is a diagram flow that is rather different 
from the diagram flow that is present in RFC 6749 Figure 1.
In Figure 3.1,  an entity combines the roles of the AS and the RS 
whereas in Figure 1 : Abstract Protocol Flow (Page 7), these two
roles are under the control of two separate entities. This means that 
the formal Model of OAuth is NOT closely following the OAuth 2.0
standard [RFC 6749].

On page 29, the text continues with:

    Our model includes clients and AS/RS that (simultaneously) support
    all four modes of operation available in OAuth and
    *can be dynamically corrupted by the adversary*.

With the ABC attack, clients are not /dynamically corrupted by an 
adversary/, since Alice and Bob voluntarily cooperate to achieve
a common goal: to cheat a RS. As a consequence, the dissertation does 
not consider collaborative clients or collusion between clients.

The same problem appeared with the ABC4Trust EU project (Attribute-based 
Credentials for Trust) which has now ended.
*U-Prove* from Microsoft and *Identity Mixer* from IBM were used as a 
demonstrating technology of the principles.
However during the project, no one ever considered the case of the Alice 
and Bob collusion attack. So all experts involved
in this project believed that these two technologies were secure, 
whereas they were not, even when smart cards were being used.

You wrote :

    " A commonly accepted security property for OAuth would be:

       An attacker should not be able to obtain access to or use a
    protected resource protected by an uncompromised AS
       if that resource is only used by an honest user with an
    uncompromised client and user agent."

This sentence has nothing to do with a "security property". This term is 
defined in ISO/IEC TS 19249:2017, 3.1:

    *security property*
    *property* of a system or application *that is crucial to achieve
    the security objectives defined for the system or application*

On the contrary, it is *c**rucial to prevent collaborative users to 
cheat a RS using an uncompromised AS*.

You also wrote:

    Being resistant to collusion attacks is not a commonly
    accepted/expected security property.

Being resistant to collusion attacks is indeed a security property.

Considering only honest users is an hypothesis that does not correspond 
to the real world. Currently, when reading the current document
even through the lines, it is impossible to guess that the ABC attack 
may ever exist.

Now, the question is : Is OAuth 2.0 able to meet such a property ? I 
read again my previous emails and the answer is ... *YES*.

I considered two cases:

    a) When the JWT contains one or more attributes that uniquely allow
    to identify the collaborative user, then the other client
    will be in a position to impersonate the collaborative user. There
    is no advantage for Alice because she will simply be able to
    impersonate Bob and she will not take any advantage of the
    attributes from Bob for herself.

    b) When the JWT does not contain a sufficient number of attributes
    that would allow to identify the user,
    the collaborative user can transmit it to anybody else, without the
    risk to be detected by the RS.  E.g. it
    only contains the age of the user and a membership to a large group
    of people. This case can only be countered
    using secure elements with specific properties.

When the token contains one or more attributes that uniquely allow to 
identify the collaborative user (e.g. a "sub" claim),
then Alice can only impersonate the collaborative user and such a case 
can easily be obtained using TeamViewer.

      * Unfortunately using the "sub" claim is not "privacy friendly",
        since collaborative RSs will be able to link the accounts
        of their respective users.  Nevertheless, this a good news for
        Vittorio, since the "sub" claim is REQUIRED in the
        "Profile for OAuth 2.0 Access Tokens". This means that, *when
        this profile is being used, OAuth 2.0 is resistant **to
        the ABC attack*.

      * Using a different claim that would only contain an identifier
        that is unique to the RS (such as a pseudo) would be
        more appropriate (as FIDO does), but I am not aware of a claim
        that has been defined which would have such a semantics.

The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
"updated to account for the potentially _dynamic relationships
involving multiple parties_. As explained above, this is not the case 
for clients since multiple clients have not been considered.
This is also not the case for RSs since multiple RSs have not been 
considered.

Anyway, in order to correctly explain the cases, there needs to be a 
discussion in this document both about the ABC attack
_and_ the content of the token. There should also be a discussion about 
multiple RSs where an RS attempts to forward a received token
to another RS. Even if the countermeasure is obvious, it should be 
mentioned in this document.

To summarize my findings about the dissertation, it is not able to 
address these cases since it only consider attackers that can either be :

  * "Web attackers (who can listen to and send messages from their own
    addresses only)" or
  * "Network attackers (who may listen to and spoof all addresses and
    therefore are the most powerful attackers)".

Denis

> Hi Denis,
>
> Am 07.05.20 um 14:46 schrieb Denis:
>> (...)
>>
>> A new definition for the term client should be adopted for this 
>> document.  However, you are right, the two wordings shall remain.
>>
> I cannot follow any of this, sorry.
>
>>>>
>>>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have 
>>>> been "updated to account for the potentially _dynamic relationships 
>>>> involving multiple parties_".
>>>> However, it still misses to address the case of _dynamic 
>>>> relationships between clients_, which include scenarios of 
>>>> _collaborative clients_.
>>>>
>>> That is not correct. Web attackers (A1) can participate in the 
>>> protocol as one or more users (resource owners) or clients. Of 
>>> course, these can collaborate between each other.
>>>
>> Section 3 states:
>>
>> *OAuth MUST ensure that* the authorization of the resource owner 
>> (RO)  (with a user agent) at the authorization server (AS) and
>>    the subsequent usage of the access token at the resource server 
>> (RS) *is protected _at least_ against the following attackers*:
>>
>>   *  (A1) *Web Attackers *(...)
>>
>> If a collaboration / collusion between clients were covered under 
>> this case, then it would mean that *OAUTH MUST provide a protection 
>> for it*,
>> whereas this is technically impossible.
>>
> You are confusing the attacker model with the security goals (aka 
> security properties).
>
> A commonly accepted security property for OAuth would be:
>
> "An attacker should not be able to obtain access to or use a protected 
> resource protected by an uncompromised AS if that resource is only 
> used by an honest user with an uncompromised client and user agent."
>
> (roughly equivalent to the one in 
> https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)
>
> Being resistant to collusion attacks is not a commonly 
> accepted/expected security property.
>
> So: Yes, attackers are free to collude, and that is part of the model. 
> No, that is not a problem, as they are not breaking anything anyone 
> would expect.
>
> -Daniel
>
>
>> Since AOuth is unable to protect against a collusion attack between 
>> clients, the collusion attack cannot belong to this section, in 
>> particular under (A1).
>>
>> Section 3 is confusing the threat model with the resistance of OAuth 
>> to these threats.
>>
>> At this time, an RFC reader may not catch the fact that a collusion 
>> attack between clients may ever exist and thus may not
>> grasp the fact that this kind of attack cannot be countered by OAuth, 
>> even when following the Best Practices.
>>
>> The "Updated OAuth 2.0 Attacker Model" does not take into "account 
>> for the potentially _dynamic relationships involving multiple parties_".
>> as it is advertised, in particular the case of _dynamic relationships 
>> between clients_ which include the case of _collaborative clients_.
>>
>> The text currently does not  incorporate words like "collusion", 
>> "colluding", whereas it should. The text should clearly indicate that
>> a protection against a collusion between clients is currently not 
>> possible using OAuth.
>>
>>>> Such a collaboration between clients is possible and should be 
>>>> considered in the "updated model".
>>>>
>>> This is considered in the model.
>>
>> See my comments above. While promised by the text, the case of 
>> collaborative clients is not considered in the model.
>>
>>>> which are human beings, it cannot be assumed that all the human 
>>>> beings in the world will necessary be honest. Whether or not Auth 
>>>> 2.0 is able or not
>>>> to counter such an attack is another issue.
>>>>
>>> This as well. 
>>
>> As said above, the model should only express the threats (or the 
>> possible attacks) and another section should indicate which threats 
>> cannot countered.
>>
>>>> In another section, it should be mentioned that OAuth 2.0 is unable 
>>>> to counter such an attack.
>>>>
>>> The problem is not that this type of collusion attack is not 
>>> possible under the model. The problem is it is not commonly expected 
>>> that OAuth protects against this type of attack.
>>>
>> RFC readers who have not followed or participated to this thread will 
>> not necessarily know that OAuth does not protect against this type of 
>> attack.
>>
>> The purpose of this document is to inform the reader about _all_ 
>> known types of attacks, whether they can be defeated or not by OAuth 2.0.
>>
>> Denis
>>
>>> -Daniel
>>>
>>>> Stating that such an attack is "out of the scope" of OAuth 2.0 
>>>> would not be an appropriate statement.
>>>>
>>>> It should not be forgotten, that the purpose of this document is to 
>>>> inform the reader about _all_ the relevant security issues.
>>>>
>>>> Denis
>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>>>>
>>>>>          Title           : OAuth 2.0 Security Best Current Practice
>>>>>          Authors         : Torsten Lodderstedt
>>>>>                            John Bradley
>>>>>                            Andrey Labunets
>>>>>                            Daniel Fett
>>>>> 	Filename        : draft-ietf-oauth-security-topics-15.txt
>>>>> 	Pages           : 46
>>>>> 	Date            : 2020-04-05
>>>>>
>>>>> Abstract:
>>>>>     This document describes best current security practice for OAuth 2.0.
>>>>>     It updates and extends the OAuth 2.0 Security Threat Model to
>>>>>     incorporate practical experiences gathered since OAuth 2.0 was
>>>>>     published and covers new threats relevant due to the broader
>>>>>     application of OAuth 2.0.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>>
>>>>> There are also htmlized versions available at:
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------9D0AA13C747E77E0117AD8D5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Daniel,

    


    

    
Thank you for pointing to your
      dissertation which has the following title : An Expressive Formal
      Model of the Web Infrastructure.

      

    

    
Since it is 240 pages long (or thick),
      I have not read everything but some sentences brought my
      attention.

    


    

    
I have experienced formal models in the
      past and everything depends upon the hypothesis that are made
      upfront.

    


    

    
On page 28:

    

    

      
1.1.1. The Web Infrastructure Model

      


      

      
(...) 

      

      
Altogether, the model is the most
          comprehensive and detailed model for the web infrastructure to
          date [i.e. in year 2018].

      
(...)

    

    
On page 40, there is the following
      sentence:

    

      
A browser is thought to be used by
          one honest user, who is modeled as part of the browser.

    

    


      With such an hypothesis, it is impossible to consider a collusion
      attack between clients, hence the Model omits to consider such a
      case.

    
When using a formal approach, it is
      generally not possible to make sure that all attacks have been
      considered, but when considering 

      specific attacks, it is possible to demonstrate that they can be
      countered (or not).

    


    

    Many models are considering "adversaries". This originates from the
    "Alice, Bob and Carol model" where both Alice and Bob 

    
were honest and where Carol was the
      attacker. In the case of the "Alice and Bob Collusion attack",
      Alice and Bob are good friends. 

      The target of the attack is a RS. The RS is not an adversary : it
      does nothing bad. Alice and Bob are adversaries towards Carol (the
      RS).

    
This can bee seen as the revenge of
      "Alice and Bob" against Carol.  :-)

    

    


    

    
On page 29, the text states:

    

      
Model of OAuth 2.0

        

      

      
Using our generic web model, we build
        a formal model of OAuth, closely following the OAuth 2.0
        standard [RFC6749].

    

    
On page 72, Figure 3.1 there is a
      diagram flow that is rather different from the diagram flow that
      is present in RFC 6749 Figure 1.

    
In Figure 3.1,  an entity combines the
      roles of the AS and the RS whereas in Figure 1 : Abstract Protocol
      Flow (Page 7), these two 

      roles are under the control of two separate entities. This means
      that the formal Model of OAuth is NOT closely following the OAuth
      2.0 

      standard [RFC 6749].

      

    

    
On page 29, the text continues with:

    

      
Our model includes clients and AS/RS
        that (simultaneously) support all four modes of operation
        available in OAuth and 

        can be dynamically corrupted by the adversary.

      

    

    
With the ABC attack, clients are not dynamically
        corrupted by an adversary, since Alice and Bob voluntarily
      cooperate to achieve 

      a common goal: to cheat a RS. As a consequence, the dissertation
      does not consider collaborative clients or collusion between
      clients. 

    


    

    

      
The same problem appeared with the
        ABC4Trust EU project (Attribute-based Credentials for Trust)
        which has now ended.

      
U-Prove from Microsoft and Identity
          Mixer from IBM were used as a demonstrating technology of
        the principles.

        However during the project, no one ever considered the case of
        the Alice and Bob collusion attack. So all experts involved 

        in this project believed that these two technologies were
        secure, whereas they were not, even when smart cards were being
        used.

    

    


    

    
 You wrote :

    

      

        
" A commonly accepted security property for OAuth would be: 

          

            An attacker should not be able to obtain access to or use a
          protected resource protected by an uncompromised AS 

            if that resource is only used by an honest user with an
          uncompromised client and user agent."

      

    

    
This sentence has nothing to do with a "security property". This
      term is defined in ISO/IEC TS 19249:2017, 3.1:

    

      
security property

        property of a system or application that is crucial
          to achieve the security objectives defined for the system or
          application

    

    
On the contrary, it is crucial to prevent
        collaborative users to cheat a RS using an uncompromised AS.
      

    

    
You also wrote:
    

    

      
Being resistant to collusion attacks is not a commonly
        accepted/expected security property.

    

    
Being resistant to collusion attacks is indeed a security
      property. 

    

    
Considering only honest users is an hypothesis that does not
      correspond to the real world. Currently, when reading the current
      document

      even through the lines, it is impossible to guess that the ABC
      attack may ever exist.
    

    
Now, the question is : Is OAuth 2.0 able to meet such a property
      ? I read again my previous emails and the answer is ... YES.
      

    

    
I considered two cases: 

    

    

      
a) When the JWT contains one or more attributes that uniquely
        allow to identify the collaborative user, then the other client
        

        will be in a position to impersonate the collaborative user.
        There is no advantage for Alice because she will simply be able
        to 

        impersonate Bob and she will not take any advantage of the
        attributes from Bob for herself.

      
b) When the JWT does not contain a sufficient number of
        attributes that would allow to identify the user,

        the collaborative user can transmit it to anybody else, without
        the risk to be detected by the RS.  E.g. it 

        only contains the age of the user and a membership to a large
        group of people. This case can only be countered 

        using secure elements with specific properties.

    

    
When the token contains one or more attributes that uniquely
      allow to identify the collaborative user (e.g. a "sub" claim), 

      then Alice can only impersonate the collaborative user and such a
      case can easily be obtained using TeamViewer.

    

    

      
    
        
  • Unfortunately using the "sub" claim is not "privacy
          friendly", since collaborative RSs will be able to link the
          accounts 
    
          of their respective users.  Nevertheless, this a good news for
          Vittorio, since the "sub" claim is REQUIRED in the 
    
          "Profile for OAuth 2.0 Access Tokens". This means that, when
            this profile is being used, OAuth 2.0 is resistant to
            
    
            the ABC attack    . 
    
          
    
        
    • 
        
  • Using a different claim that would only contain an
          identifier that is unique to the RS (such as a pseudo) would
          be
    
          more appropriate (as FIDO does), but I am not aware of a claim
          that has been defined which would have such a semantics.
    • 
      

    

    
The "Updated OAuth 2.0 Attacker Model" is
        supposed to have been "updated to account for the potentially dynamic
          relationships 

          involving multiple parties. As explained above, this is
        not the case for clients since multiple clients have not been
        considered. 

        This is also not the case for RSs since multiple RSs have not
        been considered.

    
Anyway, in order to correctly explain the cases, there needs to
      be a discussion in this document both about the ABC attack 

      and the content of the token. There should also be a
      discussion about multiple RSs where an RS attempts to forward a
      received token 

      to another RS. Even if the countermeasure is obvious, it should be
      mentioned in this document.

    
To summarize my findings about the dissertation, it is not able
      to address these cases since it only consider attackers that can
      either be :

    
    
      
  • "Web attackers (who can listen to and send messages from their
        own addresses only)" or
    • 
      
  • "Network attackers (who may listen to and spoof all addresses
        and therefore are the most powerful attackers)".
    
      
    • 
    

    
Denis

    


    

    

      
      
Hi Denis,

      

      


      

      
Am 07.05.20 um 14:46 schrieb Denis:

      

      

        
        (...)

        
A new definition for the term client should be adopted for
          this document.  However, you are right, the two wordings shall
          remain.

        

      

      
I cannot follow any of this, sorry.

      

        

          

            


              
3) The "Updated OAuth 2.0
                  Attacker Model" is supposed to have been "updated to
                  account for the potentially dynamic relationships
                    involving multiple parties". 

                  However, it still misses to address the case of dynamic
                    relationships between clients, which include
                  scenarios of collaborative clients.

                

            

          

          
That is not correct. Web attackers (A1) can participate in
            the protocol as one or more users (resource owners) or
            clients. Of course, these can collaborate between each
            other.

        

        
Section 3 states:

        
   OAuth MUST ensure that the authorization of the
          resource owner (RO)  (with a user agent) at the authorization
          server (AS) and 

             the subsequent usage of the access token at the resource
          server (RS) is protected at least against the
            following attackers:

        
  *  (A1) Web Attackers (...)

        
If a collaboration / collusion between clients were covered
          under this case, then it would mean that OAUTH MUST
            provide a protection for it, 

          whereas this is technically impossible.

        

      

      
You are confusing the attacker model with the security goals
        (aka security properties).

      
A commonly accepted security property for OAuth would be:

      
"An attacker should not be able to obtain access to or use a
        protected resource protected by an uncompromised AS if that
        resource is only used by an honest user with an uncompromised
        client and user agent."

      
(roughly equivalent to the one in
        https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)

      

      
Being resistant to collusion attacks is not a commonly
        accepted/expected security property.

      
So: Yes, attackers are free to collude, and that is part of the
        model. No, that is not a problem, as they are not breaking
        anything anyone would expect.

      

      
-Daniel

      

      


      

      

        
 

        
Since AOuth is unable to protect against a collusion attack
          between clients, the collusion attack cannot belong to this
          section, in particular under (A1).

        
Section 3 is confusing the threat model with the resistance
          of OAuth to these threats.

        
At this time, an RFC reader may not catch the fact that a
          collusion attack between clients may ever exist and thus may
          not 

          grasp the fact that this kind of attack cannot be countered by
          OAuth, even when following the Best Practices.

        
The "Updated OAuth 2.0 Attacker Model" does
            not take into "account for the potentially dynamic
              relationships involving multiple parties". 

            as it is advertised, in particular the case of dynamic
              relationships between clients which include the case
            of collaborative clients.

        
The text currently does not  incorporate words like
          "collusion", "colluding", whereas it should. The text should
          clearly indicate that 

          a protection against a collusion between clients is currently
          not possible using OAuth.

        

          

            

              
 Such a collaboration between clients is
                  possible and should be considered in the "updated
                  model". 

                

            

          

          This is considered in the model.

        

        
See my comments above. While promised by the text, the case
          of collaborative clients is not considered in the model.

        

          

            

              
 which are human beings, it cannot be
                  assumed that all the human beings in the world will
                  necessary be honest. Whether or not Auth 2.0 is able
                  or not 

                  to counter such an attack is another issue.

                

            

          

          This as well. 

        
As said above, the model should only express the threats (or
          the possible attacks) and another section should indicate
          which threats cannot countered.  

        

        

          

            

              
 

              
In another section, it should be
                  mentioned that OAuth 2.0 is unable to counter such an
                  attack.

                

            

          

          
The problem is not that this type of collusion attack is
            not possible under the model. The problem is it is not
            commonly expected that OAuth protects against this type of
            attack.

        

        
RFC readers who have not followed or participated to this
          thread will not necessarily know that OAuth does not protect
          against this type of attack.

        
The purpose of this document is to inform the
            reader about all known types of attacks, whether
            they can be defeated or not by OAuth 2.0.

        
Denis

        

          
-Daniel

          

          

            

              
 Stating that such an attack is "out of
                  the scope" of OAuth 2.0 would not be an
                  appropriate statement.

                

              
It should not be forgotten, that the
                  purpose of this document is to inform the reader about
                  all the relevant security issues.

                  

                  Denis

            

            

              
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-15.txt
	Pages           : 46
	Date            : 2020-04-05

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


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


            

            


            

            

            

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


          

          


          

          

          

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


        

        


        

        

        

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


      

      


      

      

      

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


    

    


    

  


--------------9D0AA13C747E77E0117AD8D5--


From nobody Fri May  8 06:15:29 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770343A0966 for ; Fri,  8 May 2020 06:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N78G8fJHMDLv for ; Fri,  8 May 2020 06:15:24 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165E83A0945 for ; Fri,  8 May 2020 06:15:24 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 44CDBF4074D; Fri,  8 May 2020 06:15:15 -0700 (PDT)
To: mbj@microsoft.com, dick.hardt@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: hvr@gnu.org, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200508131515.44CDBF4074D@rfc-editor.org>
Date: Fri,  8 May 2020 06:15:15 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6750 (6161)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 13:15:26 -0000

The following errata report has been submitted for RFC6750,
"The OAuth 2.0 Authorization Framework: Bearer Token Usage".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6161

--------------------------------------
Type: Editorial
Reported by: Herbert Valerio Riedel 

Section: 4

Original Text
-------------
4.  Example Access Token Response

   Typically, a bearer token is returned to the client as part of an
   OAuth 2.0 [RFC6749] access token response.  An example of such a
   response is:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8

Corrected Text
--------------
4.  Example Access Token Response

   Typically, a bearer token is returned to the client as part of an
   OAuth 2.0 [RFC6749] access token response.  An example of such a
   response is:

     HTTP/1.1 200 OK
     Content-Type: application/json

Notes
-----
The IANA registration (see https://tools.ietf.org/html/rfc8259#section-11) does not support any parameters for the `application/json` media type. The `charset=UTF-8` parameter used in the example is therefore non-compliant and ought to be omitted.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6750 (draft-ietf-oauth-v2-bearer-23)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework: Bearer Token Usage
Publication Date    : October 2012
Author(s)           : M. Jones, D. Hardt
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Fri May  8 09:17:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985813A0C4A for ; Fri,  8 May 2020 09:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYKFqkWegXFP for ; Fri,  8 May 2020 09:16:47 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF073A0CCB for ; Fri,  8 May 2020 09:16:47 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id u22so945074plq.12 for ; Fri, 08 May 2020 09:16:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=5zrBIK/gFfewezzZ3PvhwwDpyRZiuEn4G+KMkz8dMOM=; b=Ap2Jyqu6u5L8lFf1eIToT9a9U3zQw+hHs4kFahfmqLdKC6xedL6m2wL1OlYxymf6L/ KeU9c8bjvMembiFbZIN8Ol7S7ofBbH64Eh7gkt74gHHBxSk/reJgvKfV7F/wCT3UKrXY 5pnuiji1D/RPk1n+Giat2YcGuc2dYUvM45+4cZlug80B49VFs7FI0uz5n4yIzDP684Hw e8j5Vp2JgDWOh8NU+lQrUYnsTwR2cVjeVI9kd93xK20a+fGogRj0UID0JgTUrp49JR/Y Dz1Hz+N8yjCyP+iLEe7QjYylE9mVRk0JlUEOJ65Ll5VLwj9+76IB3FLhKSe6ycNKuWjd AwzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=5zrBIK/gFfewezzZ3PvhwwDpyRZiuEn4G+KMkz8dMOM=; b=f8zYeCm1G+zb9pGJrJkngl5m9nWGEUULGLZHsmlWkuRsT9kYSP49Yxk4XgPrwHoaIb Z/k7s7O9kdU3XP4A96yVDoeF4ULjMo/LuBJbFv5Enz2uJNcMN52pEnrohbnlDsp7HRJZ Yp7v0NUDAkAqOn4UxR19Oul+SKU+NHgSNDCv4cMxMRByIq4mZ+DS5KDaxrK2IscQSzOK qdfkSNLZ9oQ1BWi5Bdvidxj3YMRdtYYR6v4w+PB+9OCUQjsD4Us2j0sASPzau8JMX7ZU +N5bsnmSS9+7dWTAzjLJ5/Xz5WtV43w99c0f7A1JKXZYmFUVaOJWyniXfGLR63OmubKv RfGg==
X-Gm-Message-State: AGi0PuYK1Yr+g4tPcwJxtB+ug5H3erzLEZ17RO3nhnRs8WDaWL1qid5z 9K+g4FGY5AxKVTZ1PqWzD3IsPLCJLC8UvQ==
X-Google-Smtp-Source: APiQypKM2Edt73qqEyOKreBpecy64R9Zs0QwlMq5981bpv9ylJ8D3Ssb26bqgaNRP2z44zRxYAmY1Q==
X-Received: by 2002:a17:902:ac87:: with SMTP id h7mr3001306plr.119.1588954606283;  Fri, 08 May 2020 09:16:46 -0700 (PDT)
Received: from ?IPv6:2001:569:7a71:1d00:a011:8e51:236f:4b0e? (node-1w7jr9qrfoxx9yipdlocpzaxa.ipv6.telus.net. [2001:569:7a71:1d00:a011:8e51:236f:4b0e]) by smtp.gmail.com with ESMTPSA id m12sm1669274pgj.46.2020.05.08.09.16.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 09:16:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-1F637A3D-CF46-4035-945F-602C9386A6E2
Content-Transfer-Encoding: 7bit
From: Phillip Hunt 
Mime-Version: 1.0 (1.0)
Date: Fri, 8 May 2020 09:16:44 -0700
Message-Id: 
References: <3b016c63-facd-a1cf-cb58-6ad5d8633055@danielfett.de>
Cc: OAuth@ietf.org
In-Reply-To: <3b016c63-facd-a1cf-cb58-6ad5d8633055@danielfett.de>
To: Daniel Fett 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 16:16:53 -0000

--Apple-Mail-1F637A3D-CF46-4035-945F-602C9386A6E2
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1=20

Phil

> On May 7, 2020, at 11:50 PM, Daniel Fett  wrote:
>=20
> =EF=BB=BF
> +1 to all what Aaron said. Thanks for pointing this out!
>=20
> We need to address this in the security BCP and this will be a normative c=
hange that affects OpenID Connect Core (just as our current recommendation o=
n the usage of nonce).
>=20
> We would then have:
>=20
> - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE,=
 except if you are a public client, then you still need PKCE.
> - use state, except if you use PKCE, then you don't need state.
>=20
> I think there are very good reasons to simplify this down to=20
>=20
> - use PKCE
> - you may or may not use state
>=20
> First and foremost, not many people will understand why there are cases wh=
en the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, unders=
tanding why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not needed, b=
ut its better to use it all the time" is easy to understand. We will not see=
 many implementations following the long version above correctly.
>=20
> Second, we dramatically reduce technical complexity by reducing cases that=
 need to be handled. We reduce correctness and compliance testing complexity=
 in the same way. We reduce the cost of security analysis, which scales real=
ly badly to more cases.
>=20
> And finally, using nonce to protect against code injection is less robust t=
han PKCE. AS have a better track record than clients when it comes to correc=
tly implementing security mechanisms.=20
>=20
> Yes, this will make a number of implementations non-spec-compliant, but I d=
o not think that this is a huge problem. Software needs to adapt all the tim=
e and a software that has not been changed in a while is probably not one yo=
u would want to use anyway. We are setting a new goal for implementations to=
 meet and eventually, maintained implementations will get there.
>=20
> -Daniel
>=20
>=20
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>> Backing up a step or two, there's another point here that I think has bee=
n missed in these discussions.
>>=20
>> PKCE solves two problems: stolen authorization codes for public clients, a=
nd authorization code injection for all clients. We've only been talking abo=
ut authorization code injection on the list so far. The quoted section of th=
e security BCP (4.5.3) which says clients can do PKCE or use the nonce, is o=
nly talking about preventing authorization code injection.
>>=20
>> The nonce parameter solves authorization code injection if the client req=
uests an ID token. Public clients using the nonce parameter are still suscep=
tible to stolen authorization codes so they still need to do PKCE as well.
>>=20
>> The only case where OpenID Connect clients don't benefit from PKCE is if t=
hey are also confidential clients. Public client OIDC clients still need to d=
o PKCE even if they check the nonce.
>>=20
>> OpenID Connect servers working with confidential clients still benefit fr=
om PKCE because they can then enforce the authorization code injection prote=
ction server-side rather than cross their fingers that clients implemented t=
he nonce check properly.
>>=20
>> I really don't think it's worth the amount of explanation this will take i=
n the future to write an exception into OAuth 2.1 or the Security BCP for on=
ly some types of OpenID Connect clients when all clients would benefit from P=
KCE anyway.
>>=20
>> Aaron
>>=20
>>=20
>>=20
>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>>> Hello!
>>>=20
>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is be=
st practice for OAuth 2.0. It is not common in OpenID Connect servers as the=
 nonce solves some of the issues that PKCE protects against. We think that m=
ost OpenID Connect implementations also support OAuth 2.0, and hence have su=
pport for PKCE if following best practices.
>>>=20
>>> The advantages or requiring PKCE are:
>>>=20
>>> - a simpler programming model across all OAuth applications and profiles=
 as they all use PKCE
>>>=20
>>> - reduced attack surface when using  S256 as a fingerprint of the verifi=
er is sent through the browser instead of the clear text value
>>>=20
>>> - enforcement by AS not client - makes it easier to handle for client de=
velopers and AS can ensure the check is conducted
>>>=20
>>> What are disadvantages besides the potential impact to OpenID Connect de=
ployments? How significant is that impact?
>>>=20
>>> Dick, Aaron, and Torsten
>>>=20
>>> =E1=90=A7
>>=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-1F637A3D-CF46-4035-945F-602C9386A6E2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 

Phil
=


On May 7, 2020, at 11:50 PM, D=
aniel Fett <fett@danielfett.de> wrote:

=EF=BB=BF
 =20
    
 =20
 =20
    
+1 to all what Aaron said. Thanks for
      pointing this out!

    


    

    
We need to address this in the security
      BCP and this will be a normative change that affects OpenID
      Connect Core (just as our current recommendation on the usage of
      nonce).

    

    


    

    
We would then have:

    


    

    
- use PKCE, except if you use OIDC with
      a nonce, then you don't need PKCE, except if you are a public
      client, then you still need PKCE.

    
- use state, except if you use PKCE,
      then you don't need state.

    


    

    
I think there are very good reasons to
      simplify this down to 

    

    


    

    
- use PKCE

    
- you may or may not use state

    


    

    
First and foremost, not many people
      will understand why there are cases when the BCP/OAuth 2.1 mandate
      PKCE and some where they don't. However, understanding why
      you have to do something is key to compliance. The short version
      "PKCE protects the code; there is a specific case where it is not
      needed, but its better to use it all the time" is easy to
      understand. We will not see many implementations following the
      long version above correctly.

    


    

    
Second, we dramatically reduce
      technical complexity by reducing cases that need to be handled. We
      reduce correctness and compliance testing complexity in the same
      way. We reduce the cost of security analysis, which scales really
      badly to more cases.

    


    

    
And finally, using nonce to protect
      against code injection is less robust than PKCE. AS have a better
      track record than clients when it comes to correctly implementing
      security mechanisms. 

    

    


    

    
Yes, this will make a number of
      implementations non-spec-compliant, but I do not think that this
      is a huge problem. Software needs to adapt all the time and a
      software that has not been changed in a while is probably not one
      you would want to use anyway. We are setting a new goal for
      implementations to meet and eventually, maintained implementations
      will get there.

    

    


    

    
-Daniel

    

    


    

    


    

    
Am 08.05.20 um 01:38 schrieb Aaron
      Parecki:

    

    

      
      

        
Backing up a step or two, there's another point
          here that I think has been missed in these discussions.
          


          

          
PKCE solves two problems: stolen authorization codes for
            public clients, and authorization code injection for all
            clients. We've only been talking about authorization code
            injection on the list so far. The quoted section of the
            security BCP (4.5.3) which says clients can do PKCE or use
            the nonce, is only talking about preventing authorization
            code injection.

          


          

          
The nonce parameter solves authorization code injection
            if the client requests an ID token. Public clients using the
            nonce parameter are still susceptible to stolen
            authorization codes so they still need to do PKCE as well.
=

          


          

          
The only case where OpenID Connect clients don't benefit
            from PKCE is if they are also confidential clients. Public
            client OIDC clients still need to do PKCE even if they check
            the nonce.

          


          

          
OpenID Connect servers working with confidential clients
            still benefit from PKCE because they can then enforce the
            authorization code injection protection
            server-side rather than cross their fingers that clien=
ts
            implemented the nonce check properly.

          


          

          
I really don't think it's worth the amount of explanation
            this will take in the future to write an exception into
            OAuth 2.1 or the Security BCP for only some types of OpenID
            Connect clients when all clients would benefit from PKCE
            anyway.

          


          

          
Aaron

          


          

        

        


        

        

        

          
On Wed, May 6, 2020 at 10:48=

            AM Dick Hardt <dick.hardt@gmail.com> wrote:

          

          

            

              
Hello!
                


                

                
We would like to have PKCE be a MUST in OAuth 2.1
                  code flows. This is best practice for OAuth 2.0. It is
                  not common in OpenID Connect servers as the nonce
                  solves some of the issues that PKCE protects against.
                  We think that most OpenID Connect implementations also
                  support OAuth 2.0, and hence have support for PKCE if=

                  following best practices.

                


                

                
The advantages or requiring PKCE are:

                


                

                
- a simpler programming model across all OAuth
                  applications and profiles as they all use PKCE

                


                

                
- reduced attack surface when using  S256 as a
                  fingerprint of the verifier is sent through the
                  browser instead of the clear text value

                


                

                
- enforcement by AS not client - makes it easier to
                  handle for client developers and AS can ensure the
                  check is conducted

                

                


                

                
What are disadvantages besides the potential impact
                  to OpenID Connect deployments? How significant is that
                  impact?

                


                

                
Dick, Aaron, and Torsten

                


                

              

            

            
=3D""=E1=90=A7

          

        

      

      

      

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


    

    


    

 =20

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

--Apple-Mail-1F637A3D-CF46-4035-945F-602C9386A6E2--


From nobody Fri May  8 09:55:41 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA03A0B43 for ; Fri,  8 May 2020 09:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-_lJhlCRgwR for ; Fri,  8 May 2020 09:55:34 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650103.outbound.protection.outlook.com [40.107.65.103]) (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 5768D3A0AD1 for ; Fri,  8 May 2020 09:55:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gi1KiEmEYJUSIvM1NWwcDY2NWjm2fs3iFox4MuTVJHPBqlzjp7gSEq3fXOLtc1Xqr5Z88xIliA4GD/OAPwtlVuQHdtjmIa15GLvEzoxNuosf0Lf28hWZ8OY9LA6ck8FyFhkegH8OAUoEuM0AfrHl97AYh1Fe1zJKyHyLDXm9nWvHJhjd3itZ3qCAmsozVWjGeijLQrcoWIjemIWTnjpxhAYnHAIZ1q4yJfx0aVdG1Zd+UFRDh5tWs3Gmp172xJ/TlotwywyzzDMgEQ8dVLF4/+1V3wd7NPxw9GMKKk42pyD5NjC/1Dw8aceW6GHhMSBQBVJxH4zMHkCP80bZrWzb4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ydh3GRISUNblPROkdgcJN0As75BBSIZ0sXMJih45FQI=; b=Uneeh+i3fwnWi6UGRL8qpNp7qXW8q8FWorV/pntGyP3Sh9xB58p3BA1hSR05SKMErftUw0qMqMBRST1IVMj4uESwU3/2V9PenXDravpaH12cDnlY/FDXf01qsX7EBP1dLk8jPrxQFSyRIsW7gEMvqjZPQ4tUP+utgfVmtB87LFosWcwndR6YXSKRZO1djzT5/1/wVHlUYLSVoa95UF7JHA/zdKwrDxs2qzQfrmKLoS2l3Wwc5N/4/aZnyJcpTSKvoy6E7q9DOdfTyTIKOJTTmZjKdjFhC9FGLaZtUxiQnWh/tzz7j3PimBMqyZj/iQSsBwQ/sHABxmOwzId1UUfV4A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ydh3GRISUNblPROkdgcJN0As75BBSIZ0sXMJih45FQI=; b=Enh1XM2tCupbohcno8FkwUTPxLQtAnTm67/o1z4gCQe8F5KLxUIa1urJ72rN9LdBgWgLfVmgGvVaTyVcFKNQpXFD7eNKi0U1EhnIJySrZcHDy+DIFSlukBLozur0S72tu9pJTXQ7Bqj/NDsA5NuN4A3uGxnIF4Ho+rOev+/K+k0=
Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0553.namprd00.prod.outlook.com (2603:10b6:5:165::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.0; Fri, 8 May 2020 16:55:17 +0000
Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::28ba:39bb:f9ca:658b%5]) with mapi id 15.20.3015.000; Fri, 8 May 2020 16:55:17 +0000
From: Mike Jones 
To: Daniel Fett , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYlWXAnmjsqG17TS+ukF4wvi0+THQ==
Date: Fri, 8 May 2020 16:55:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b4c71a8d-cafc-4e3b-85b6-0000c0573b66; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-08T16:45:41Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: danielfett.de; dkim=none (message not signed) header.d=none;danielfett.de; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b756775d-dfb6-4e84-e911-08d7f37095f3
x-ms-traffictypediagnostic: DM6PR00MB0553:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 039735BC4E
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: buaYxgcytbO69AamAwkvlNUY7ODZ9QedzW/8yqYGFc/qgpGUeB/wmNnKSONjYwl6aajURNOm+Kh3PqaqN4KGVVVX3+8PUFfNbpbD7APPylBh6nZNxOS9WPVzERwIsf0FtNgZzaL3HpUvtodxuz1xgWFS9NV/QuWxWXEUP9pSMk3HtmX6MXGlParskF4XLOLrZ67W6ZKSorUkiy2/8MWAB/vLhm5GVT7opY/CY4NnHsXnTwxdDf7fd8eimH+FEuGR6OT6Sf6fKK0NZpAyZUok54rEwMr4oKqqx+SKxeWb3A1QlvOkLL+yuJACAyGV3U91oTjCVKPP2Uxkg8kekVBrY/3EKk3L81yIcTMesKTtWhiPW6nWbupTkEA4axUxvOZAewetCTdvdbFKCkudUxOb3E3j/pENxcUQ48H1jGi99tr2bV9Ge/0TWCZJ2BHzKNh8XpqKWITIkS9p56LGmONhGHK8ZCRmqIqbMG4I+Lp1HpD8qfnz7fGcKSE9QRNE8GJX4rn+Q88AkWoyKbxbq/T5cA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(33430700001)(8990500004)(33656002)(52536014)(110136005)(7696005)(966005)(66946007)(76116006)(316002)(82950400001)(82960400001)(33440700001)(76236002)(66446008)(66476007)(64756008)(2906002)(53546011)(9686003)(66556008)(5660300002)(6506007)(478600001)(83280400001)(8936002)(55016002)(83300400001)(83290400001)(66574014)(83310400001)(83320400001)(166002)(10290500003)(71200400001)(8676002)(26005)(186003)(86362001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: ouj9DjBu4UqQbh68yIILjc+a+PcRhX0YJ77UDptGhyqFfurzRH75HhJ9H+Kg3/bguyFt9AsfR4XucnlOnkyLSdMtoty9ERUInVPRpKR5H9ndJ+H+Jphbm7Jg49bXZZvlucEI1Aa/CWNWZJUn1x4AscdWSjp1McDqvf7MUANwet9V3mzf2eNpoAQrf2POy2w3k/xZtjsnHVHlen5U4i1lTanP0mD6AKLZw7kQi67hZJo5pQWwCFBtfqyzLd/289+ucDlg/TP86vIQe9Vcbl4mhGJyRZ1xSbSpJ7xhKwQL3xEQGabmvKN4cR1Z0cSArSwbNce5o67nGx0A2J4InS2F9cu62stIq1JtQEOfdMfmomyOUqbwN4px0JjDKMwZZgRXRrcq5Dn+zHMZ9m04WPcanoqsvboh2nD7YU1M6yo6fhsjhJLD2PFDks9y20jq9ZbCHzGUBCJH2BjpyLxksgKLtD99aLimH6Xx0BnbbWOrRcw=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0684CD35E5A1E7F4309983B0F5A20DM6PR00MB0684namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b756775d-dfb6-4e84-e911-08d7f37095f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 16:55:17.3293 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xm6TEkhjckYB3/J5GGpVvTiCN385C5x7Ga2DhBFNiEhJ+4ButDAzmpAc/j82F0FkRIxmCaCtdSHu09AHZo2Bcw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0553
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 16:55:39 -0000

--_000_DM6PR00MB0684CD35E5A1E7F4309983B0F5A20DM6PR00MB0684namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGFuaWVsLCB5b3Ugd3JvdGU6DQo+IFdlIHdvdWxkIHRoZW4gaGF2ZToNCj4gLSB1c2UgUEtDRSwg
ZXhjZXB0IGlmIHlvdSB1c2UgT0lEQyB3aXRoIGEgbm9uY2UsIHRoZW4geW91IGRvbid0IG5lZWQg
UEtDRSwgZXhjZXB0IGlmIHlvdSBhcmUgYSBwdWJsaWMgY2xpZW50LCB0aGVuIHlvdSBzdGlsbCBu
ZWVkIFBLQ0UuDQo+IC0gdXNlIHN0YXRlLCBleGNlcHQgaWYgeW91IHVzZSBQS0NFLCB0aGVuIHlv
dSBkb24ndCBuZWVkIHN0YXRlLg0KDQpJIGJlbGlldmUgdGhhdCB0aGlzIGlzIGFuIGFjY3VyYXRl
IHN0YXRlbWVudCBvZiB0aGUgZmFjdHMsIGJhbGFuY2luZyBpbnRlcm9wZXJhYmlsaXR5IGFuZCBz
aW1wbGljaXR5LiAgVGhhdOKAmXMgd2hhdCB3ZSBzaG91bGQgdGhlcmVmb3JlIHNheSBpbiB0aGUg
c3BlYyAocG9zc2libHkgcmV3b3JkaW5nIGl0IHRvIG1ha2UgaXQgZWFzaWVyIHRvIHBhcnNlIGFu
ZCB1bmRlcnN0YW5kKS4NCg0KSSB3b3VsZCBiZSBPSyBnb2luZyBzbyBmYXIgYXMgYWxzbyBzYXlp
bmcgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZjoNCiAgLSBBbHRlcm5hdGl2ZWx5LCBuZXcg
aW1wbGVtZW50YXRpb25zIG1heSBjaG9vc2UgdG8gYWx3YXlzIHVzZSBQS0NFLCBwcm92aWRlZCB0
aGF0IHRoZSBjbGllbnQgc29tZWhvdyBjYW4gZGV0ZXJtaW5lIHRoYXQgdGhlIHNlcnZlciBpdCBp
cyBjb21tdW5pY2F0aW5nIHdpdGggYWxzbyBzdXBwb3J0cyBQS0NFLg0KVGhhdCBzZWVtcyBsaWtl
IGEgdmlhYmxlIGNvbXByb21pc2UsIGdpdmluZyBkZXZlbG9wZXJzIGFjY3VyYXRlIGluZm9ybWF0
aW9uIHRoYXQgaXMgYWN0aW9uYWJsZS4NCg0KQnV0IG1hbmRhdGluZyBQS0NFIGluIGFsbCBjYXNl
cywgZXZlbiB3aGVuIHVubmVjZXNzYXJ5LCB3b3VsZCBiZSBhbiBpbnRlcm9wIGRpc2FzdGVyIGFu
ZCB3b3VsZCBjYXVzZSBtYW55IHRvIHNpbXBseSBpZ25vcmUgdGhlIG5ldyBzcGVjLg0KDQpPQXV0
aCAyLjEgd2FzIHN1cHBvc2VkIHRvIG5vdCBpbnRyb2R1Y2UgYnJlYWtpbmcgY2hhbmdlcy4gIElm
IHlvdSB3YW50IHRvIGRvIHRoYXQsIHBsZWFzZSBkbyBpdCBpbiBUeEF1dGggaW5zdGVhZC4NCg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t
IE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBP
ZiBEYW5pZWwgRmV0dA0KU2VudDogVGh1cnNkYXksIE1heSA3LCAyMDIwIDExOjUwIFBNDQpUbzog
b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVp
cmUgUEtDRT8NCg0KKzEgdG8gYWxsIHdoYXQgQWFyb24gc2FpZC4gVGhhbmtzIGZvciBwb2ludGlu
ZyB0aGlzIG91dCENCg0KV2UgbmVlZCB0byBhZGRyZXNzIHRoaXMgaW4gdGhlIHNlY3VyaXR5IEJD
UCBhbmQgdGhpcyB3aWxsIGJlIGEgbm9ybWF0aXZlIGNoYW5nZSB0aGF0IGFmZmVjdHMgT3BlbklE
IENvbm5lY3QgQ29yZSAoanVzdCBhcyBvdXIgY3VycmVudCByZWNvbW1lbmRhdGlvbiBvbiB0aGUg
dXNhZ2Ugb2Ygbm9uY2UpLg0KDQpXZSB3b3VsZCB0aGVuIGhhdmU6DQoNCi0gdXNlIFBLQ0UsIGV4
Y2VwdCBpZiB5b3UgdXNlIE9JREMgd2l0aCBhIG5vbmNlLCB0aGVuIHlvdSBkb24ndCBuZWVkIFBL
Q0UsIGV4Y2VwdCBpZiB5b3UgYXJlIGEgcHVibGljIGNsaWVudCwgdGhlbiB5b3Ugc3RpbGwgbmVl
ZCBQS0NFLg0KLSB1c2Ugc3RhdGUsIGV4Y2VwdCBpZiB5b3UgdXNlIFBLQ0UsIHRoZW4geW91IGRv
bid0IG5lZWQgc3RhdGUuDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHZlcnkgZ29vZCByZWFzb25zIHRv
IHNpbXBsaWZ5IHRoaXMgZG93biB0bw0KDQotIHVzZSBQS0NFDQotIHlvdSBtYXkgb3IgbWF5IG5v
dCB1c2Ugc3RhdGUNCg0KRmlyc3QgYW5kIGZvcmVtb3N0LCBub3QgbWFueSBwZW9wbGUgd2lsbCB1
bmRlcnN0YW5kIHdoeSB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUgQkNQL09BdXRoIDIuMSBtYW5k
YXRlIFBLQ0UgYW5kIHNvbWUgd2hlcmUgdGhleSBkb24ndC4gSG93ZXZlciwgdW5kZXJzdGFuZGlu
ZyB3aHkgeW91IGhhdmUgdG8gZG8gc29tZXRoaW5nIGlzIGtleSB0byBjb21wbGlhbmNlLiBUaGUg
c2hvcnQgdmVyc2lvbiAiUEtDRSBwcm90ZWN0cyB0aGUgY29kZTsgdGhlcmUgaXMgYSBzcGVjaWZp
YyBjYXNlIHdoZXJlIGl0IGlzIG5vdCBuZWVkZWQsIGJ1dCBpdHMgYmV0dGVyIHRvIHVzZSBpdCBh
bGwgdGhlIHRpbWUiIGlzIGVhc3kgdG8gdW5kZXJzdGFuZC4gV2Ugd2lsbCBub3Qgc2VlIG1hbnkg
aW1wbGVtZW50YXRpb25zIGZvbGxvd2luZyB0aGUgbG9uZyB2ZXJzaW9uIGFib3ZlIGNvcnJlY3Rs
eS4NCg0KU2Vjb25kLCB3ZSBkcmFtYXRpY2FsbHkgcmVkdWNlIHRlY2huaWNhbCBjb21wbGV4aXR5
IGJ5IHJlZHVjaW5nIGNhc2VzIHRoYXQgbmVlZCB0byBiZSBoYW5kbGVkLiBXZSByZWR1Y2UgY29y
cmVjdG5lc3MgYW5kIGNvbXBsaWFuY2UgdGVzdGluZyBjb21wbGV4aXR5IGluIHRoZSBzYW1lIHdh
eS4gV2UgcmVkdWNlIHRoZSBjb3N0IG9mIHNlY3VyaXR5IGFuYWx5c2lzLCB3aGljaCBzY2FsZXMg
cmVhbGx5IGJhZGx5IHRvIG1vcmUgY2FzZXMuDQoNCkFuZCBmaW5hbGx5LCB1c2luZyBub25jZSB0
byBwcm90ZWN0IGFnYWluc3QgY29kZSBpbmplY3Rpb24gaXMgbGVzcyByb2J1c3QgdGhhbiBQS0NF
LiBBUyBoYXZlIGEgYmV0dGVyIHRyYWNrIHJlY29yZCB0aGFuIGNsaWVudHMgd2hlbiBpdCBjb21l
cyB0byBjb3JyZWN0bHkgaW1wbGVtZW50aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQoNClllcywg
dGhpcyB3aWxsIG1ha2UgYSBudW1iZXIgb2YgaW1wbGVtZW50YXRpb25zIG5vbi1zcGVjLWNvbXBs
aWFudCwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBhIGh1Z2UgcHJvYmxlbS4gU29m
dHdhcmUgbmVlZHMgdG8gYWRhcHQgYWxsIHRoZSB0aW1lIGFuZCBhIHNvZnR3YXJlIHRoYXQgaGFz
IG5vdCBiZWVuIGNoYW5nZWQgaW4gYSB3aGlsZSBpcyBwcm9iYWJseSBub3Qgb25lIHlvdSB3b3Vs
ZCB3YW50IHRvIHVzZSBhbnl3YXkuIFdlIGFyZSBzZXR0aW5nIGEgbmV3IGdvYWwgZm9yIGltcGxl
bWVudGF0aW9ucyB0byBtZWV0IGFuZCBldmVudHVhbGx5LCBtYWludGFpbmVkIGltcGxlbWVudGF0
aW9ucyB3aWxsIGdldCB0aGVyZS4NCg0KLURhbmllbA0KDQoNCkFtIDA4LjA1LjIwIHVtIDAxOjM4
IHNjaHJpZWIgQWFyb24gUGFyZWNraToNCkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUn
cyBhbm90aGVyIHBvaW50IGhlcmUgdGhhdCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVz
ZSBkaXNjdXNzaW9ucy4NCg0KUEtDRSBzb2x2ZXMgdHdvIHByb2JsZW1zOiBzdG9sZW4gYXV0aG9y
aXphdGlvbiBjb2RlcyBmb3IgcHVibGljIGNsaWVudHMsIGFuZCBhdXRob3JpemF0aW9uIGNvZGUg
aW5qZWN0aW9uIGZvciBhbGwgY2xpZW50cy4gV2UndmUgb25seSBiZWVuIHRhbGtpbmcgYWJvdXQg
YXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBvbiB0aGUgbGlzdCBzbyBmYXIuIFRoZSBxdW90
ZWQgc2VjdGlvbiBvZiB0aGUgc2VjdXJpdHkgQkNQICg0LjUuMykgd2hpY2ggc2F5cyBjbGllbnRz
IGNhbiBkbyBQS0NFIG9yIHVzZSB0aGUgbm9uY2UsIGlzIG9ubHkgdGFsa2luZyBhYm91dCBwcmV2
ZW50aW5nIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uDQoNClRoZSBub25jZSBwYXJhbWV0
ZXIgc29sdmVzIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gaWYgdGhlIGNsaWVudCByZXF1
ZXN0cyBhbiBJRCB0b2tlbi4gUHVibGljIGNsaWVudHMgdXNpbmcgdGhlIG5vbmNlIHBhcmFtZXRl
ciBhcmUgc3RpbGwgc3VzY2VwdGlibGUgdG8gc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgc28g
dGhleSBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgYXMgd2VsbC4NCg0KVGhlIG9ubHkgY2FzZSB3aGVy
ZSBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIGRvbid0IGJlbmVmaXQgZnJvbSBQS0NFIGlzIGlmIHRo
ZXkgYXJlIGFsc28gY29uZmlkZW50aWFsIGNsaWVudHMuIFB1YmxpYyBjbGllbnQgT0lEQyBjbGll
bnRzIHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBldmVuIGlmIHRoZXkgY2hlY2sgdGhlIG5vbmNlLg0K
DQpPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIHdvcmtpbmcgd2l0aCBjb25maWRlbnRpYWwgY2xpZW50
cyBzdGlsbCBiZW5lZml0IGZyb20gUEtDRSBiZWNhdXNlIHRoZXkgY2FuIHRoZW4gZW5mb3JjZSB0
aGUgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBwcm90ZWN0aW9uIHNlcnZlci1zaWRlIHJh
dGhlciB0aGFuIGNyb3NzIHRoZWlyIGZpbmdlcnMgdGhhdCBjbGllbnRzIGltcGxlbWVudGVkIHRo
ZSBub25jZSBjaGVjayBwcm9wZXJseS4NCg0KSSByZWFsbHkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0
aCB0aGUgYW1vdW50IG9mIGV4cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtlIGluIHRoZSBmdXR1cmUg
dG8gd3JpdGUgYW4gZXhjZXB0aW9uIGludG8gT0F1dGggMi4xIG9yIHRoZSBTZWN1cml0eSBCQ1Ag
Zm9yIG9ubHkgc29tZSB0eXBlcyBvZiBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIHdoZW4gYWxsIGNs
aWVudHMgd291bGQgYmVuZWZpdCBmcm9tIFBLQ0UgYW55d2F5Lg0KDQpBYXJvbg0KDQoNCg0KT24g
V2VkLCBNYXkgNiwgMjAyMCBhdCAxMDo0OCBBTSBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls
LmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkhlbGxvIQ0KDQpXZSB3
b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUgZmxvd3Mu
IFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29tbW9uIGlu
IE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9mIHRoZSBp
c3N1ZXMgdGhhdCBQS0NFIHByb3RlY3RzIGFnYWluc3QuIFdlIHRoaW5rIHRoYXQgbW9zdCBPcGVu
SUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBzdXBwb3J0IE9BdXRoIDIuMCwgYW5kIGhl
bmNlIGhhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMuDQoN
ClRoZSBhZHZhbnRhZ2VzIG9yIHJlcXVpcmluZyBQS0NFIGFyZToNCg0KLSBhIHNpbXBsZXIgcHJv
Z3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHByb2ZpbGVz
IGFzIHRoZXkgYWxsIHVzZSBQS0NFDQoNCi0gcmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3aGVuIHVz
aW5nICBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlmaWVyIGlzIHNlbnQgdGhyb3Vn
aCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZhbHVlDQoNCi0gZW5mb3Jj
ZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUgZm9yIGNs
aWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25kdWN0ZWQN
Cg0KV2hhdCBhcmUgZGlzYWR2YW50YWdlcyBiZXNpZGVzIHRoZSBwb3RlbnRpYWwgaW1wYWN0IHRv
IE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlmaWNhbnQgaXMgdGhhdCBpbXBh
Y3Q/DQoNCkRpY2ssIEFhcm9uLCBhbmQgVG9yc3Rlbg0KDQrhkKcNCg0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlz
dA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo=

--_000_DM6PR00MB0684CD35E5A1E7F4309983B0F5A20DM6PR00MB0684namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz
O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw
LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu
OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t
LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N
CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s
PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs
aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5EYW5pZWwsIHlvdSB3cm90ZTo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFdlIHdvdWxkIHRo
ZW4gaGF2ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgLSB1c2Ug
UEtDRSwgZXhjZXB0IGlmIHlvdSB1c2UgT0lEQyB3aXRoIGEgbm9uY2UsIHRoZW4geW91IGRvbid0
IG5lZWQgUEtDRSwgZXhjZXB0IGlmIHlvdSBhcmUgYSBwdWJsaWMgY2xpZW50LCB0aGVuIHlvdSBz
dGlsbCBuZWVkIFBLQ0UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7
IC0gdXNlIHN0YXRlLCBleGNlcHQgaWYgeW91IHVzZSBQS0NFLCB0aGVuIHlvdSBkb24ndCBuZWVk
IHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGJlbGlldmUgdGhhdCB0aGlz
IGlzIGFuIGFjY3VyYXRlIHN0YXRlbWVudCBvZiB0aGUgZmFjdHMsIGJhbGFuY2luZyBpbnRlcm9w
ZXJhYmlsaXR5IGFuZCBzaW1wbGljaXR5LiZuYnNwOyBUaGF04oCZcyB3aGF0IHdlIHNob3VsZCB0
aGVyZWZvcmUgc2F5IGluIHRoZSBzcGVjIChwb3NzaWJseSByZXdvcmRpbmcgaXQgdG8gbWFrZSBp
dCBlYXNpZXIgdG8gcGFyc2UgYW5kIHVuZGVyc3RhbmQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwMjA2MCI+SSB3b3VsZCBiZSBPSyBnb2luZyBzbyBmYXIgYXMgYWxzbyBzYXlpbmcg
c29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7IC0gQWx0
ZXJuYXRpdmVseSwgbmV3IGltcGxlbWVudGF0aW9ucyBtYXkgY2hvb3NlIHRvIGFsd2F5cyB1c2Ug
UEtDRSwgcHJvdmlkZWQgdGhhdCB0aGUgY2xpZW50IHNvbWVob3cgY2FuIGRldGVybWluZSB0aGF0
IHRoZSBzZXJ2ZXIgaXQgaXMgY29tbXVuaWNhdGluZyB3aXRoIGFsc28gc3VwcG9ydHMgUEtDRS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwMjA2MCI+VGhhdCBzZWVtcyBsaWtlIGEgdmlhYmxlIGNvbXByb21pc2UsIGdpdmlu
ZyBkZXZlbG9wZXJzIGFjY3VyYXRlIGluZm9ybWF0aW9uIHRoYXQgaXMgYWN0aW9uYWJsZS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkJ1dCBtYW5kYXRpbmcgUEtDRSBpbiBh
bGwgY2FzZXMsIGV2ZW4gd2hlbiB1bm5lY2Vzc2FyeSwgd291bGQgYmUgYW4gaW50ZXJvcCBkaXNh
c3RlciBhbmQgd291bGQgY2F1c2UgbWFueSB0byBzaW1wbHkgaWdub3JlIHRoZSBuZXcgc3BlYy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk9BdXRoIDIuMSB3YXMgc3VwcG9z
ZWQgdG8gbm90IGludHJvZHVjZSBicmVha2luZyBjaGFuZ2VzLiZuYnNwOyBJZiB5b3Ugd2FudCB0
byBkbyB0aGF0LCBwbGVhc2UgZG8gaXQgaW4gVHhBdXRoIGluc3RlYWQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBC
ZWhhbGYgT2YgPC9iPg0KRGFuaWVsIEZldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1h
eSA3LCAyMDIwIDExOjUwIFBNPGJyPg0KPGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIHRvIGFs
bCB3aGF0IEFhcm9uIHNhaWQuIFRoYW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQhPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIG5lZWQgdG8g
YWRkcmVzcyB0aGlzIGluIHRoZSBzZWN1cml0eSBCQ1AgYW5kIHRoaXMgd2lsbCBiZSBhIG5vcm1h
dGl2ZSBjaGFuZ2UgdGhhdCBhZmZlY3RzIE9wZW5JRCBDb25uZWN0IENvcmUgKGp1c3QgYXMgb3Vy
IGN1cnJlbnQgcmVjb21tZW5kYXRpb24gb24gdGhlIHVzYWdlIG9mIG5vbmNlKS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd291bGQgdGhl
biBoYXZlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4tIHVzZSBQS0NFLCBleGNlcHQgaWYgeW91IHVzZSBPSURDIHdpdGggYSBub25jZSwgdGhl
biB5b3UgZG9uJ3QgbmVlZCBQS0NFLCBleGNlcHQgaWYgeW91IGFyZSBhIHB1YmxpYyBjbGllbnQs
IHRoZW4geW91IHN0aWxsIG5lZWQgUEtDRS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gdXNlIHN0YXRlLCBleGNlcHQgaWYgeW91IHVzZSBQS0NF
LCB0aGVuIHlvdSBkb24ndCBuZWVkIHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZXJlIGFyZSB2ZXJ5IGdvb2QgcmVh
c29ucyB0byBzaW1wbGlmeSB0aGlzIGRvd24gdG8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHVzZSBQS0NFPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHlvdSBtYXkgb3IgbWF5IG5vdCB1
c2Ugc3RhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Rmlyc3QgYW5kIGZvcmVtb3N0LCBub3QgbWFueSBwZW9wbGUgd2lsbCB1bmRlcnN0YW5k
IHdoeSB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUgQkNQL09BdXRoIDIuMSBtYW5kYXRlIFBLQ0Ug
YW5kIHNvbWUgd2hlcmUgdGhleSBkb24ndC4gSG93ZXZlciwgdW5kZXJzdGFuZGluZw0KPGk+d2h5
PC9pPiB5b3UgaGF2ZSB0byBkbyBzb21ldGhpbmcgaXMga2V5IHRvIGNvbXBsaWFuY2UuIFRoZSBz
aG9ydCB2ZXJzaW9uICZxdW90O1BLQ0UgcHJvdGVjdHMgdGhlIGNvZGU7IHRoZXJlIGlzIGEgc3Bl
Y2lmaWMgY2FzZSB3aGVyZSBpdCBpcyBub3QgbmVlZGVkLCBidXQgaXRzIGJldHRlciB0byB1c2Ug
aXQgYWxsIHRoZSB0aW1lJnF1b3Q7IGlzIGVhc3kgdG8gdW5kZXJzdGFuZC4gV2Ugd2lsbCBub3Qg
c2VlIG1hbnkgaW1wbGVtZW50YXRpb25zIGZvbGxvd2luZw0KIHRoZSBsb25nIHZlcnNpb24gYWJv
dmUgY29ycmVjdGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5TZWNvbmQsIHdlIGRyYW1hdGljYWxseSByZWR1Y2UgdGVjaG5pY2FsIGNvbXBs
ZXhpdHkgYnkgcmVkdWNpbmcgY2FzZXMgdGhhdCBuZWVkIHRvIGJlIGhhbmRsZWQuIFdlIHJlZHVj
ZSBjb3JyZWN0bmVzcyBhbmQgY29tcGxpYW5jZSB0ZXN0aW5nIGNvbXBsZXhpdHkgaW4gdGhlIHNh
bWUgd2F5LiBXZSByZWR1Y2UgdGhlIGNvc3Qgb2Ygc2VjdXJpdHkgYW5hbHlzaXMsIHdoaWNoIHNj
YWxlcyByZWFsbHkgYmFkbHkgdG8NCiBtb3JlIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgZmluYWxseSwgdXNpbmcgbm9uY2Ug
dG8gcHJvdGVjdCBhZ2FpbnN0IGNvZGUgaW5qZWN0aW9uIGlzIGxlc3Mgcm9idXN0IHRoYW4gUEtD
RS4gQVMgaGF2ZSBhIGJldHRlciB0cmFjayByZWNvcmQgdGhhbiBjbGllbnRzIHdoZW4gaXQgY29t
ZXMgdG8gY29ycmVjdGx5IGltcGxlbWVudGluZyBzZWN1cml0eSBtZWNoYW5pc21zLg0KPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhp
cyB3aWxsIG1ha2UgYSBudW1iZXIgb2YgaW1wbGVtZW50YXRpb25zIG5vbi1zcGVjLWNvbXBsaWFu
dCwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBhIGh1Z2UgcHJvYmxlbS4gU29mdHdh
cmUgbmVlZHMgdG8gYWRhcHQgYWxsIHRoZSB0aW1lIGFuZCBhIHNvZnR3YXJlIHRoYXQgaGFzIG5v
dCBiZWVuIGNoYW5nZWQgaW4gYSB3aGlsZSBpcyBwcm9iYWJseSBub3Qgb25lIHlvdSB3b3VsZCB3
YW50DQogdG8gdXNlIGFueXdheS4gV2UgYXJlIHNldHRpbmcgYSBuZXcgZ29hbCBmb3IgaW1wbGVt
ZW50YXRpb25zIHRvIG1lZXQgYW5kIGV2ZW50dWFsbHksIG1haW50YWluZWQgaW1wbGVtZW50YXRp
b25zIHdpbGwgZ2V0IHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4tRGFuaWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gMDguMDUuMjAgdW0gMDE6Mzggc2NocmllYiBBYXJv
biBQYXJlY2tpOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+QmFja2luZyB1cCBhIHN0ZXAgb3IgdHdvLCB0aGVyZSdzIGFub3RoZXIg
cG9pbnQgaGVyZSB0aGF0IEkgdGhpbmsgaGFzIGJlZW4gbWlzc2VkIGluIHRoZXNlIGRpc2N1c3Np
b25zLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QS0NF
IHNvbHZlcyB0d28gcHJvYmxlbXM6IHN0b2xlbiBhdXRob3JpemF0aW9uIGNvZGVzIGZvciBwdWJs
aWMgY2xpZW50cywgYW5kIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gZm9yIGFsbCBjbGll
bnRzLiBXZSd2ZSBvbmx5IGJlZW4gdGFsa2luZyBhYm91dCBhdXRob3JpemF0aW9uIGNvZGUgaW5q
ZWN0aW9uIG9uIHRoZSBsaXN0IHNvIGZhci4gVGhlIHF1b3RlZCBzZWN0aW9uIG9mIHRoZSBzZWN1
cml0eQ0KIEJDUCAoNC41LjMpIHdoaWNoIHNheXMgY2xpZW50cyBjYW4gZG8gUEtDRSBvciB1c2Ug
dGhlIG5vbmNlLCBpcyBvbmx5IHRhbGtpbmcgYWJvdXQgcHJldmVudGluZyBhdXRob3JpemF0aW9u
IGNvZGUgaW5qZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGUgbm9uY2UgcGFyYW1ldGVyIHNvbHZlcyBhdXRob3JpemF0aW9uIGNv
ZGUgaW5qZWN0aW9uIGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gSUQgdG9rZW4uIFB1YmxpYyBj
bGllbnRzIHVzaW5nIHRoZSBub25jZSBwYXJhbWV0ZXIgYXJlIHN0aWxsIHN1c2NlcHRpYmxlIHRv
IHN0b2xlbiBhdXRob3JpemF0aW9uIGNvZGVzIHNvIHRoZXkgc3RpbGwgbmVlZCB0byBkbyBQS0NF
IGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoZSBvbmx5IGNhc2Ugd2hlcmUgT3BlbklEIENvbm5lY3QgY2xpZW50cyBkb24ndCBi
ZW5lZml0IGZyb20gUEtDRSBpcyBpZiB0aGV5IGFyZSBhbHNvIGNvbmZpZGVudGlhbCBjbGllbnRz
LiBQdWJsaWMgY2xpZW50IE9JREMgY2xpZW50cyBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgZXZlbiBp
ZiB0aGV5IGNoZWNrIHRoZSBub25jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T3BlbklEIENvbm5lY3Qgc2VydmVycyB3b3JraW5nIHdpdGgg
Y29uZmlkZW50aWFsIGNsaWVudHMgc3RpbGwgYmVuZWZpdCBmcm9tIFBLQ0UgYmVjYXVzZSB0aGV5
IGNhbiB0aGVuIGVuZm9yY2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gcHJvdGVj
dGlvbiBzZXJ2ZXItc2lkZSZuYnNwO3JhdGhlciZuYnNwO3RoYW4gY3Jvc3MgdGhlaXIgZmluZ2Vy
cyB0aGF0IGNsaWVudHMgaW1wbGVtZW50ZWQgdGhlIG5vbmNlIGNoZWNrDQogcHJvcGVybHkuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVh
bGx5IGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdGhlIGFtb3VudCBvZiBleHBsYW5hdGlvbiB0aGlz
IHdpbGwgdGFrZSBpbiB0aGUgZnV0dXJlIHRvIHdyaXRlIGFuIGV4Y2VwdGlvbiBpbnRvIE9BdXRo
IDIuMSBvciB0aGUgU2VjdXJpdHkgQkNQIGZvciBvbmx5IHNvbWUgdHlwZXMgb2YgT3BlbklEIENv
bm5lY3QgY2xpZW50cyB3aGVuIGFsbCBjbGllbnRzIHdvdWxkIGJlbmVmaXQgZnJvbSBQS0NFIGFu
eXdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+QWFyb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIFdlZCwgTWF5IDYsIDIwMjAgYXQgMTA6NDggQU0gRGljayBIYXJkdCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyEgPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBi
ZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUgZmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBm
b3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29tbW9uIGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMg
YXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9mIHRoZSBpc3N1ZXMgdGhhdCBQS0NFIHByb3RlY3Rz
IGFnYWluc3QuIFdlIHRoaW5rIHRoYXQgbW9zdCBPcGVuSUQgQ29ubmVjdA0KIGltcGxlbWVudGF0
aW9ucyBhbHNvIHN1cHBvcnQgT0F1dGggMi4wLCBhbmQgaGVuY2UmbmJzcDtoYXZlIHN1cHBvcnQg
Zm9yIFBLQ0UgaWYgZm9sbG93aW5nIGJlc3QgcHJhY3RpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYWR2YW50YWdlcyBvciByZXF1
aXJpbmcgUEtDRSBhcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPi0gYSBzaW1wbGVyIHByb2dyYW1taW5nIG1vZGVsIGFjcm9zcyBhbGwgT0F1
dGggYXBwbGljYXRpb25zIGFuZCBwcm9maWxlcyBhcyB0aGV5IGFsbCB1c2UgUEtDRTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHJlZHVjZWQg
YXR0YWNrIHN1cmZhY2Ugd2hlbiB1c2luZyZuYnNwOyBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2Yg
dGhlIHZlcmlmaWVyIGlzIHNlbnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBj
bGVhciB0ZXh0IHZhbHVlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPi0gZW5mb3JjZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVh
c2llciB0byBoYW5kbGUgZm9yIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRo
ZSBjaGVjayBpcyBjb25kdWN0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBhcmUgZGlzYWR2YW50YWdlcyBiZXNpZGVzIHRoZSBwb3Rl
bnRpYWwgaW1wYWN0IHRvIE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlmaWNh
bnQgaXMgdGhhdCBpbXBhY3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkRpY2ssIEFhcm9uLCBhbmQgVG9yc3RlbjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGlt
ZyBib3JkZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hl
aWdodDouMDEwNGluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5h
cHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0
eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5LWIyODQ3NDRi
YzE3MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1
Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1
dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9B
dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_DM6PR00MB0684CD35E5A1E7F4309983B0F5A20DM6PR00MB0684namp_--


From nobody Fri May  8 12:36:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618E33A0E08 for ; Fri,  8 May 2020 12:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUOYFOvFxgPV for ; Fri,  8 May 2020 12:36:47 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5153A088E for ; Fri,  8 May 2020 12:36:47 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id e25so2889046ljg.5 for ; Fri, 08 May 2020 12:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b5qG9XqH2UJHwozvd2cA+ls8DE625bzCDhukRin4DE0=; b=NytgR+A3jOZDvArGBl1kh02Dpa+W4nqt5F7G4qa27eflCFJWr+Qw697YSY2N1KY0oy NI0IXo37J7TZj7myGPVsa6DCeamqmobwNfgyBiaJMDW9iltG8u55X1VnmDNlcOqFPjxY FDX6R/I+Goi8Y1h5mIg014SgyLZ7vbNTBEYDtAVpcBE/NGQoQLh5WydDcen2xMnKXSIh r+YJeMlokqFCZCtoHD9nX8vch1r1JDkfS0piGAUGRNcrjWrWGSga0xslccmSAhzYci79 DF4r/uu71h+OIKXzZbnnETkCYsLA+E6EWnobcaijitC8zerNKPTU62SIOy2pQGACia49 CnQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b5qG9XqH2UJHwozvd2cA+ls8DE625bzCDhukRin4DE0=; b=kUqmInRcV1U/5uCe/7yvYXYiZdRrkDX85YB5U6hYdy7bizW6rsw81GMfIvrb0G6wBH s/9sw8tRC+p5QXSOlXL6NWYI5oKgaW+rCbc/kDkHLJMMVuOClj5I70c4DYyjHQULv6zG 26LdCPoogDR4hh5q13fABZ57Pq3z+ngqyZcSnWaAbUH2V6xrYM3G6Vc4onU+PSoGw2Do xzyzuX0lnDVd1cLAio+w62RPz0eMnE8k+jNeIT5Nae9JQcbFtqbiKLecBwTcsNej3DTh PdKBJA+ieKpS101R19gvLQAAWF+PdtpOOaHCDAYre8Ig62SWY9uUZtGZzSUiAbFSR07d Jugw==
X-Gm-Message-State: AOAM531CfeV2OsSKL3B8QbB6sAJKCy2AKY7Q+8FrcxSKCT9UyCz04wXu YVtCcYnbe7CkNNW7fOxucLpGcoRe3BgUGt39lq+f0cic
X-Google-Smtp-Source: ABdhPJzye4dzSSAC6MfeCk54+ZlnOmGlVa3zujxgtTOdbKLP9v9tHYYMgOeEKFoTKYGdmnSWavkwSybiLldwhbxluYE=
X-Received: by 2002:a2e:b891:: with SMTP id r17mr2782595ljp.34.1588966605461;  Fri, 08 May 2020 12:36:45 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 8 May 2020 12:36:17 -0700
Message-ID: 
To: Philippe De Ryck 
Cc: Mike Jones ,  Aaron Parecki , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000141c8505a5281ec6"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 19:36:51 -0000

--000000000000141c8505a5281ec6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is
OAuth 2.0 with best practices.

On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck <
philippe@pragmaticwebsecurity.com> wrote:

> From working with a lot of developers on understanding OAuth 2.0 and OIDC=
,
> I definitely vote for simplicity. Understanding the subtle nuances of whe=
n
> a nonce is fine and when PKCE should be used is impossible without in-dep=
th
> knowledge of the flows and their properties. Misunderstandings will cause
> security vulnerabilities, which can easily be avoided.
>
> Since OAuth 2.1 is a separate spec, I don=E2=80=99t really see a problem =
with
> existing code not being compliant. They support OAuth 2.0, and if they wa=
nt
> to be OAuth 2.1 compliant, they add PKCE. If I=E2=80=99m not mistaken, ot=
her
> requirements of OAuth 2.1 would also clash with existing deployments (e.g=
.,
> using non-exact redirect URIs).
>
> I believe that optimizing for making OAuth 2.1 easier to understand will
> yield the highest return.
>
> Philippe
>
>
> On 8 May 2020, at 03:42, Mike Jones <
> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>
> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  You=
=E2=80=99re
> concerned about =E2=80=9Cthe amount of explanation this will take=E2=80=
=9D.  That=E2=80=99s
> optimizing for spec simplicity =E2=80=93 a goal that I do understand.  Ho=
wever, by
> writing these few sentences or paragraphs, we=E2=80=99ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won=
=E2=80=99t
> have to change their deployments.  That=E2=80=99s optimizing for interope=
rability
> and minimizing the burden on developers, which are far more important.
>
> As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have very d=
ifferent
> ramifications on interoperability=E2=80=9D.
>
> Even if you=E2=80=99re optimizing for writing, taking a minimally invasiv=
e
> protocol change approach will optimize that, overall.  If we proceed as
> you=E2=80=99re suggesting, a huge amount of writing will occur on StackOv=
erflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask =E2=80=9CWhy do I have to change my deployed code?=E2=
=80=9D with the
> answers being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99s no=
 need to change
> your deployed code.=E2=80=9D
>
> I=E2=80=99d gladly write a few sentences in our new specs now to prevent =
ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you=E2=80=99re ready to incorporate them into the spec text.
>
>                                                        -- Mike
>
> *From:* Aaron Parecki 
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt 
> *Cc:* OAuth WG ; Torsten Lodderstedt <
> torsten@lodderstedt.net>; Mike Jones 
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
> Backing up a step or two, there's another point here that I think has bee=
n
> missed in these discussions.
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE a=
s
> well.
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP fo=
r
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
> Aaron
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> Hello!
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
> The advantages or requiring PKCE are:
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
> Dick, Aaron, and Torsten
>
> =E1=90=A7
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--000000000000141c8505a5281ec6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


FYI: An objective of OAuth 2.1 is not to introduce anythin=
g new -- it is OAuth 2.0 with best practices.=C2=A0

On Thu, May 7, 2020 at 1=
0:36 PM Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:
From working with a lot of developers on understanding OAuth 2.0 and=
 OIDC, I definitely vote for simplicity. Understanding the subtle nuances o=
f when a nonce is fine and when PKCE should be used is impossible without i=
n-depth knowledge of the flows and their properties. Misunderstandings will=
 cause security vulnerabilities, which can easily be avoided.

Since OAuth 2.1 is a separate spec, I don=E2=80=99t really see a prob=
lem with existing code not being compliant. They support OAuth 2.0, and if =
they want to be OAuth 2.1 compliant, they add PKCE. If I=E2=80=99m not mist=
aken, other requirements of OAuth 2.1 would also clash with existing deploy=
ments (e.g., using non-exact redirect URIs).

I bel=
ieve that optimizing for making OAuth 2.1 easier to understand will yield t=
he highest return.

Philippe




On 8 May 2020, at 03:42, Mike Jones=
 <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:=


Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.=
=C2=A0 You=E2=80=99re concerned about =E2=80=9Cthe amount of explana=
tion this will take=E2=80=9D.=C2=A0 That=
=E2=80=99s optimizing for spec simplicity =E2=80=93 a goal that I do unders=
tand.=C2=A0 However, by writing these few sentences or paragraphs, we=E2=80=
=99ll make it clear to developers that hundreds or thousands of deployed Op=
enID Connect RPs won=E2=80=99t have to change their deployments.=C2=A0 That=
=E2=80=99s optimizing for interoperability and minimizing the burden on dev=
elopers, which are far more important.
=
=C2=A0
As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have very different ramifications on intero=
perability=E2=80=9D.
=C2=A0
Even if you=E2=80=99=
re optimizing for writing, taking a minimally invasive protocol change appr=
oach will optimize that, overall.=C2=A0 If we proceed as you=E2=80=99re sug=
gesting, a huge amount of writing will occur on StackOverflow, Medium, Slas=
hDot, blogs, and other developer forums, where confused developers will ask=
 =E2=80=9CWhy do I have to change my deployed code?=E2=80=9D with the answe=
rs being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99s no need t=
o change your deployed code.=E2=80=9D
=
=C2=A0
I=E2=80=99d gladly write a few senten=
ces in our new specs now to prevent ongoing confusion and interop problems =
that would otherwise result.=C2=A0 Let me know when you=E2=80=99re ready to=
 incorporate them into the spec text.
=
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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
From:=C2=A0Aaron Parecki <aaron@parecki.com>=C2=A0
Sent:=C2=
=A0Thursday, May 7, 2020 4:39 PM
To:=C2=A0Dic=
k Hardt <dick.hardt@gmail.com>
<=
b>Cc:=C2=A0OAuth WG <oauth@ietf=
.org>; Torsten Lodderstedt <tors=
ten@lodderstedt.net>; Mike Jones <Michael.Jones@microsoft.com>
Subject:=C2=A0Re: OAuth 2.1 - require PKCE?
=C2=A0
Backing up a step or two, there'=
;s another point here that I think has been missed in these discussions.=

=C2=A0
PKCE solves two problems: stolen authorization codes for public clients=
, and authorization code injection for all clients. We've only been tal=
king about authorization code injection on the list so far. The quoted sect=
ion of the security BCP (4.5.3) which says clients can do PKCE or use the n=
once, is only talking about preventing authorization code injection.=

=C2=A0
The nonce parameter solves authorization code injection if the client=
 requests an ID token. Public clients using the nonce parameter are still s=
usceptible to stolen authorization codes so they still need to do PKCE as w=
ell.
=C2=A0
The only case where OpenID Connect clients don't benef=
it from PKCE is if they are also confidential clients. Public client OIDC c=
lients still need to do PKCE even if they check the nonce.
=C2=A0
Open=
ID Connect servers working with confidential clients still benefit from PKC=
E because they can then enforce the authorization code injection protection=
 server-side=C2=A0rather=C2=A0than cross their fingers that clients impleme=
nted the nonce check properly.
<=
/u>=C2=A0
I really don't think it'=
s worth the amount of explanation this will take in the future to write an =
exception into OAuth 2.1 or the Security BCP for only some types of OpenID =
Connect clients when all clients would benefit from PKCE anyway.<=
/u>
=C2=A0
=C2=A0
<=
/div>
=C2=A0
=
=C2=A0
On Wed, May 6, 2020 at 10:48 AM Dick=
 Hardt <dick.hardt@gmail.com> wrote=
:
Hello!=

=C2=A0
We would like to have PKCE be a MUST in OAuth 2.1 code flows. This i=
s best practice for OAuth 2.0. It is not common in OpenID Connect servers a=
s the nonce solves some of the issues that PKCE protects against. We think =
that most OpenID Connect implementations also support OAuth 2.0, and hence=
=C2=A0have support for PKCE if following best practices.
=C2=A0
The ad=
vantages or requiring PKCE are:
=
=C2=A0
- a simpler programming model a=
cross all OAuth applications and profiles as they all use PKCE
=C2=A0
=
- reduced attack surface when using=C2=A0 S256 as a fingerprint of the veri=
fier is sent through the browser instead of the clear text value<=
/u>
=C2=A0
=C2=A0
What are disad=
vantages besides the potential impact to OpenID Connect deployments? How si=
gnificant is that impact?
=
=C2=A0
Dick, Aaron, and Torsten<=
/u>
=C2=A0
<=
div>
=E1=90=A7
<=
span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v=
ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;t=
ext-decoration:none;float:none;display:inline">____________________________=
___________________
OAuth mailing list
OA=
uth@ietf.org
https://=
www.ietf.org/mailman/listinfo/oauth

<=
/div>

--000000000000141c8505a5281ec6--


From nobody Fri May  8 12:42:44 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78C93A088E for ; Fri,  8 May 2020 12:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pKEwHrI6tm4 for ; Fri,  8 May 2020 12:42:20 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451F63A0C44 for ; Fri,  8 May 2020 12:42:20 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id a2so9230209oia.11 for ; Fri, 08 May 2020 12:42:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OXQsGbhPJH23QmnAZvmF0NaZP39H+SM+vtqepqk9+rQ=; b=ZuzDiTfZ49etseFEMQyuIUJfbohNPmmuldX9U8v0Wv/LBi5sEekThXTRMLGCXOXswb mnWOSDNI8scFfSWrnwRXTeyCyJ91gM/LeBVEwxPZ6mfkMfmL26wGiqx1LgIsuK+6P8lk RbY5pWz79uzod5fReQZkycDyE/InyOjbBkCq3AQ9AkP4Bj1uo3mWGMoYAxRDsp/mjrKF nreePIPTAHB26+RTZYbprKaF0NhAtrb0jlwd6LbcqIrOjh3fwEOgZhaP+1bsPUQjcD5B dqmdq7qSyAkRJ6xPLeVNvp/6mGGpmNdh76jR8MlOOLFa+4HeqFtychm+CKNgwMh4A6Qm rk0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OXQsGbhPJH23QmnAZvmF0NaZP39H+SM+vtqepqk9+rQ=; b=HsoTVee8PGfhu8FMbnTdXtDuIne27YWhMRAzavb1foHWCeo3lNauRiSYY8ItoJRNxA DtNY0A7lf4F582LwgZjpAuB5h6YxiVYDKB2io+L2299QPvL4ubQG91bd8RQzT5RNyNj5 aYN3Lz2vh7YvdgHYOljDwK4T4FPihx747tobdyJvGkYZZy+b+1wkq3ZA63a3izgNgNqU MwYJtx6E6VpNHWmprP7hpwcTwJYXUZer9uA98KDFrSZCCEpLD76bV6RB+P39X+2EK54r 4wDyWixnPe8ghC3ujHBWvg1BvpkNgqgHebJtBmui0m52h5hT0+UUws1x7Zg1o4l73D6S kYfw==
X-Gm-Message-State: AGi0PuaLhDAMxzS4T7JNctsBtL5XSdnfQYjOXy5gs4mnvKZaxuOb3NJ0 HaTEEuEB74k99+qZ7wo52oWvY5Ws8X0=
X-Google-Smtp-Source: APiQypKxhB07mT4c0vko2fsraBDMcNVi84aQE2GnKbEjmGzHPVF7T5v25HBh9UyMKZe88ebohL/YJQ==
X-Received: by 2002:aca:1c08:: with SMTP id c8mr11634202oic.172.1588966938597;  Fri, 08 May 2020 12:42:18 -0700 (PDT)
Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com. [209.85.167.176]) by smtp.gmail.com with ESMTPSA id a124sm657022oib.43.2020.05.08.12.42.17 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 12:42:17 -0700 (PDT)
Received: by mail-oi1-f176.google.com with SMTP id b18so9442762oic.6 for ; Fri, 08 May 2020 12:42:17 -0700 (PDT)
X-Received: by 2002:a54:4512:: with SMTP id l18mr10871666oil.81.1588966937186;  Fri, 08 May 2020 12:42:17 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Aaron Parecki 
Date: Fri, 8 May 2020 12:42:05 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dick Hardt 
Cc: Philippe De Ryck ,  Mike Jones , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000d9d89f05a528314d"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 19:42:26 -0000

--000000000000d9d89f05a528314d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is
OAuth 2.0 with best practices.

The line there is kind of fuzzy. The objective is not to introduce new
concepts, however there are some changes defined that are "breaking
changes" from plain OAuth 2.0, because those things being removed were not
best practices for example.

> Understanding the subtle nuances of when a nonce is fine and when PKCE
should be used is impossible without in-depth knowledge of the flows and
their properties. Misunderstandings will cause security vulnerabilities,
which can easily be avoided.

Thank you Philippe. And yes, many existing OAuth 2.0 deployments would
already need to change in order to be compliant with OAuth 2.1, just like
they would need to change to update to the latest recommendations of the
Security BCP.


On Fri, May 8, 2020 at 12:36 PM Dick Hardt  wrote:

> FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is
> OAuth 2.0 with best practices.
>
> On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck <
> philippe@pragmaticwebsecurity.com> wrote:
>
>> From working with a lot of developers on understanding OAuth 2.0 and
>> OIDC, I definitely vote for simplicity. Understanding the subtle nuances=
 of
>> when a nonce is fine and when PKCE should be used is impossible without
>> in-depth knowledge of the flows and their properties. Misunderstandings
>> will cause security vulnerabilities, which can easily be avoided.
>>
>> Since OAuth 2.1 is a separate spec, I don=E2=80=99t really see a problem=
 with
>> existing code not being compliant. They support OAuth 2.0, and if they w=
ant
>> to be OAuth 2.1 compliant, they add PKCE. If I=E2=80=99m not mistaken, o=
ther
>> requirements of OAuth 2.1 would also clash with existing deployments (e.=
g.,
>> using non-exact redirect URIs).
>>
>> I believe that optimizing for making OAuth 2.1 easier to understand will
>> yield the highest return.
>>
>> Philippe
>>
>>
>> On 8 May 2020, at 03:42, Mike Jones <
>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>>
>> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  You=
=E2=80=99re
>> concerned about =E2=80=9Cthe amount of explanation this will take=E2=80=
=9D.  That=E2=80=99s
>> optimizing for spec simplicity =E2=80=93 a goal that I do understand.  H=
owever, by
>> writing these few sentences or paragraphs, we=E2=80=99ll make it clear t=
o
>> developers that hundreds or thousands of deployed OpenID Connect RPs won=
=E2=80=99t
>> have to change their deployments.  That=E2=80=99s optimizing for interop=
erability
>> and minimizing the burden on developers, which are far more important.
>>
>> As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have very
>> different ramifications on interoperability=E2=80=9D.
>>
>> Even if you=E2=80=99re optimizing for writing, taking a minimally invasi=
ve
>> protocol change approach will optimize that, overall.  If we proceed as
>> you=E2=80=99re suggesting, a huge amount of writing will occur on StackO=
verflow,
>> Medium, SlashDot, blogs, and other developer forums, where confused
>> developers will ask =E2=80=9CWhy do I have to change my deployed code?=
=E2=80=9D with the
>> answers being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99s n=
o need to change
>> your deployed code.=E2=80=9D
>>
>> I=E2=80=99d gladly write a few sentences in our new specs now to prevent=
 ongoing
>> confusion and interop problems that would otherwise result.  Let me know
>> when you=E2=80=99re ready to incorporate them into the spec text.
>>
>>                                                        -- Mike
>>
>> *From:* Aaron Parecki 
>> *Sent:* Thursday, May 7, 2020 4:39 PM
>> *To:* Dick Hardt 
>> *Cc:* OAuth WG ; Torsten Lodderstedt <
>> torsten@lodderstedt.net>; Mike Jones 
>> *Subject:* Re: OAuth 2.1 - require PKCE?
>>
>> Backing up a step or two, there's another point here that I think has
>> been missed in these discussions.
>>
>> PKCE solves two problems: stolen authorization codes for public clients,
>> and authorization code injection for all clients. We've only been talkin=
g
>> about authorization code injection on the list so far. The quoted sectio=
n
>> of the security BCP (4.5.3) which says clients can do PKCE or use the
>> nonce, is only talking about preventing authorization code injection.
>>
>> The nonce parameter solves authorization code injection if the client
>> requests an ID token. Public clients using the nonce parameter are still
>> susceptible to stolen authorization codes so they still need to do PKCE =
as
>> well.
>>
>> The only case where OpenID Connect clients don't benefit from PKCE is if
>> they are also confidential clients. Public client OIDC clients still nee=
d
>> to do PKCE even if they check the nonce.
>>
>> OpenID Connect servers working with confidential clients still benefit
>> from PKCE because they can then enforce the authorization code injection
>> protection server-side rather than cross their fingers that clients
>> implemented the nonce check properly.
>>
>> I really don't think it's worth the amount of explanation this will take
>> in the future to write an exception into OAuth 2.1 or the Security BCP f=
or
>> only some types of OpenID Connect clients when all clients would benefit
>> from PKCE anyway.
>>
>> Aaron
>>
>>
>>
>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>>
>> Hello!
>>
>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>> best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as
>> the nonce solves some of the issues that PKCE protects against. We think
>> that most OpenID Connect implementations also support OAuth 2.0, and
>> hence have support for PKCE if following best practices.
>>
>> The advantages or requiring PKCE are:
>>
>> - a simpler programming model across all OAuth applications and profiles
>> as they all use PKCE
>>
>> - reduced attack surface when using  S256 as a fingerprint of the
>> verifier is sent through the browser instead of the clear text value
>>
>> - enforcement by AS not client - makes it easier to handle for client
>> developers and AS can ensure the check is conducted
>>
>> What are disadvantages besides the potential impact to OpenID Connect
>> deployments? How significant is that impact?
>>
>> Dick, Aaron, and Torsten
>>
>> =E1=90=A7
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>

--000000000000d9d89f05a528314d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> FYI: An objective of OAuth 2.1 is not to introduce an=
ything new -- it is OAuth 2.0 with best practices.=C2=A0

The line there is kind of fuzzy. The objective is not to introduce new con=
cepts, however there are some changes defined that are "breaking chang=
es" from plain OAuth 2.0, because those things being removed were not =
best practices for example.=C2=A0

>=C2=A0Unders=
tanding the subtle nuances of when a nonce is fine and when PKCE should be =
used is impossible without in-depth knowledge of the flows and their proper=
ties. Misunderstandings will cause security vulnerabilities, which can easi=
ly be avoided.

Thank you Philippe. And yes, many e=
xisting OAuth 2.0 deployments would already need to change in order to be c=
ompliant with OAuth 2.1, just like they would need to change to update to t=
he latest recommendations of the Security BCP.

On Fri, =
May 8, 2020 at 12:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: An objective of OAuth 2.1 is =
not to introduce anything new -- it is OAuth 2.0 with best practices.=C2=A0=


=
On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck <philippe@pragmaticwebsecur=
ity.com> wrote:
From working with a lot of developers on understanding OAuth 2.=
0 and OIDC, I definitely vote for simplicity. Understanding the subtle nuan=
ces of when a nonce is fine and when PKCE should be used is impossible with=
out in-depth knowledge of the flows and their properties. Misunderstandings=
 will cause security vulnerabilities, which can easily be avoided.

=

Since OAuth 2.1 is a separate spec, I don=E2=80=99t really see a=
 problem with existing code not being compliant. They support OAuth 2.0, an=
d if they want to be OAuth 2.1 compliant, they add PKCE. If I=E2=80=99m not=
 mistaken, other requirements of OAuth 2.1 would also clash with existing d=
eployments (e.g., using non-exact redirect URIs).

=
I believe that optimizing for making OAuth 2.1 easier to understand will yi=
eld the highest return.

Philippe




On 8 May 2020, at 03:42, Mike Jones=
 <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:=


Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.=
=C2=A0 You=E2=80=99re concerned about =E2=80=9Cthe amount of explana=
tion this will take=E2=80=9D.=C2=A0 That=
=E2=80=99s optimizing for spec simplicity =E2=80=93 a goal that I do unders=
tand.=C2=A0 However, by writing these few sentences or paragraphs, we=E2=80=
=99ll make it clear to developers that hundreds or thousands of deployed Op=
enID Connect RPs won=E2=80=99t have to change their deployments.=C2=A0 That=
=E2=80=99s optimizing for interoperability and minimizing the burden on dev=
elopers, which are far more important.
=
=C2=A0
As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have very different ramifications on intero=
perability=E2=80=9D.
=C2=A0
Even if you=E2=80=99=
re optimizing for writing, taking a minimally invasive protocol change appr=
oach will optimize that, overall.=C2=A0 If we proceed as you=E2=80=99re sug=
gesting, a huge amount of writing will occur on StackOverflow, Medium, Slas=
hDot, blogs, and other developer forums, where confused developers will ask=
 =E2=80=9CWhy do I have to change my deployed code?=E2=80=9D with the answe=
rs being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99s no need t=
o change your deployed code.=E2=80=9D
=
=C2=A0
I=E2=80=99d gladly write a few senten=
ces in our new specs now to prevent ongoing confusion and interop problems =
that would otherwise result.=C2=A0 Let me know when you=E2=80=99re ready to=
 incorporate them into the spec text.
=
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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
From:=C2=A0Aaron Parecki <aaron@parecki.com>=C2=A0
Sent:=C2=
=A0Thursday, May 7, 2020 4:39 PM
To:=C2=A0Dic=
k Hardt <dick.hardt@gmail.com>
<=
b>Cc:=C2=A0OAuth WG <oauth@ietf=
.org>; Torsten Lodderstedt <tors=
ten@lodderstedt.net>; Mike Jones <Michael.Jones@microsoft.com>
Subject:=C2=A0Re: OAuth 2.1 - require PKCE?
=C2=A0
Backing up a step or two, there'=
;s another point here that I think has been missed in these discussions.=

=C2=A0
PKCE solves two problems: stolen authorization codes for public clients=
, and authorization code injection for all clients. We've only been tal=
king about authorization code injection on the list so far. The quoted sect=
ion of the security BCP (4.5.3) which says clients can do PKCE or use the n=
once, is only talking about preventing authorization code injection.=

=C2=A0
The nonce parameter solves authorization code injection if the client=
 requests an ID token. Public clients using the nonce parameter are still s=
usceptible to stolen authorization codes so they still need to do PKCE as w=
ell.
=C2=A0
The only case where OpenID Connect clients don't benef=
it from PKCE is if they are also confidential clients. Public client OIDC c=
lients still need to do PKCE even if they check the nonce.
=C2=A0
Open=
ID Connect servers working with confidential clients still benefit from PKC=
E because they can then enforce the authorization code injection protection=
 server-side=C2=A0rather=C2=A0than cross their fingers that clients impleme=
nted the nonce check properly.
<=
/u>=C2=A0
I really don't think it'=
s worth the amount of explanation this will take in the future to write an =
exception into OAuth 2.1 or the Security BCP for only some types of OpenID =
Connect clients when all clients would benefit from PKCE anyway.<=
/u>
=C2=A0
=C2=A0
<=
/div>
=C2=A0
=
=C2=A0
On Wed, May 6, 2020 at 10:48 AM Dick=
 Hardt <dick.hardt@gmail.com> wrote=
:
Hello!=

=C2=A0
We would like to have PKCE be a MUST in OAuth 2.1 code flows. This i=
s best practice for OAuth 2.0. It is not common in OpenID Connect servers a=
s the nonce solves some of the issues that PKCE protects against. We think =
that most OpenID Connect implementations also support OAuth 2.0, and hence=
=C2=A0have support for PKCE if following best practices.
=C2=A0
The ad=
vantages or requiring PKCE are:
=
=C2=A0
- a simpler programming model a=
cross all OAuth applications and profiles as they all use PKCE
=C2=A0
=
- reduced attack surface when using=C2=A0 S256 as a fingerprint of the veri=
fier is sent through the browser instead of the clear text value<=
/u>
=C2=A0
=C2=A0
What are disad=
vantages besides the potential impact to OpenID Connect deployments? How si=
gnificant is that impact?
=
=C2=A0
Dick, Aaron, and Torsten<=
/u>
=C2=A0
<=
div>
=E1=90=A7
=
_______________________________________________
<=
span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v=
ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;t=
ext-decoration:none;float:none;display:inline">OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--000000000000d9d89f05a528314d--


From nobody Fri May  8 12:45:41 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40CC3A0DF2 for ; Fri,  8 May 2020 12:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQCeaNwJ3P-p for ; Fri,  8 May 2020 12:45:34 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76563A0CC9 for ; Fri,  8 May 2020 12:45:33 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id f15so1183640plr.3 for ; Fri, 08 May 2020 12:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=7keUDgniwQ31af4kJER8Esz+5AQ6TytioDByXnaZS34=; b=Ne0yXWG3ZroFcB/ppt6M4LEaMu4Hihu4NUeQROplsBpwoAi16nBAUfBc5HXCCsCQRo hAUZH3VhahZmmgvkYdH6VyyQzNoapDgcZKdUt4ElM2Hi2//k1qL7p5Qi1TOSFEJqXg5L Ou1ExDhI8Xpte/SdKpWBHpvJFQ0fpbPPaHGSCivXrosU0N8xPF+zAcIFdoc9KwZbtIow w7l/3mLRHcmdkqde3xzTnagN2tvJfC4fpxSjyS9cEQw2Ir2dJ/lre3JvrHMQIiMEfPza 1NFecQPWuas/tRmqUAcZzpx/Wjlbfwh8wvQsGd37JTSVkJIQz33SRlawoIWv1iocSED4 9l/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=7keUDgniwQ31af4kJER8Esz+5AQ6TytioDByXnaZS34=; b=phR2Ke/s8UYtRPMeode6w8RdD9eLtRzQU8AKjVbAn/4x+OQLxPR6/+mpF6q+3NPfok fPGx+d/7siq3bgodQuRBXiCCR66LB7wH+/cJmqO9JJNAFr4UqmuaKP7jTTmgR2U0HhQe taiv2AnHojb5qS0ggjPqSi2JRZiQDcEhtiiVWZZW49jZUMVzvUETv4yD+JIYoRBOAqr8 TW+MfEpjfam7e2oGSSmgmeegkL9ZCuED95o7GwK8YXx2OYtKt5Y6Bgez3Ab2euCeG0Io hmmJ1fRJTlm0YCWmF7tv58EnvVUBBAM6br6cbOIPbH3rrNv39Hpp0IkcAS08AW/7FLb8 AS5A==
X-Gm-Message-State: AGi0PuY+/4I4VJISol705ZxSva9dvEIVyT18t24yLDyxP+QgCltNzAIB sWLIZoMohd1zh4ukNGm4KZOL0Q==
X-Google-Smtp-Source: APiQypKYkdGKOLDFxHV+wfZJUqIefMARGsjcc9JF2zLpGifKZJt4GwpHx0Eogjeda9rBNeCVe2aHrg==
X-Received: by 2002:a17:902:b7c9:: with SMTP id v9mr3961525plz.197.1588967133048;  Fri, 08 May 2020 12:45:33 -0700 (PDT)
Received: from ?IPv6:2605:8d80:446:a45b:fca2:5799:6003:37be? ([2605:8d80:446:a45b:fca2:5799:6003:37be]) by smtp.gmail.com with ESMTPSA id 207sm1918755pgh.34.2020.05.08.12.45.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 12:45:32 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-2AFEB999-6A9D-4159-9BA2-0ACC741106E4
Content-Transfer-Encoding: 7bit
From: Phillip Hunt 
Mime-Version: 1.0 (1.0)
Date: Fri, 8 May 2020 12:45:28 -0700
Message-Id: <4BEF6231-6D2B-43A0-8E73-21FC9E45BBC4@independentid.com>
References: 
Cc: Philippe De Ryck , Mike Jones , OAuth WG 
In-Reply-To: 
To: Dick Hardt 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 19:45:39 -0000

--Apple-Mail-2AFEB999-6A9D-4159-9BA2-0ACC741106E4
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

We are not discussing anything new here. We are discussing adoption of best p=
ractice.=20

The disconnect appears to be that one dependent standard=E2=80=99s =E2=80=9C=
typical=E2=80=9D use (nonces) does not have the ietf consensus as best pract=
ice.=20

This lack of consensus needs to be resolved.=20

Phil

> On May 8, 2020, at 12:37 PM, Dick Hardt  wrote:
>=20
> =EF=BB=BF
> FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is O=
Auth 2.0 with best practices.=20
>=20
>> On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck  wrote:
>> =46rom working with a lot of developers on understanding OAuth 2.0 and OI=
DC, I definitely vote for simplicity. Understanding the subtle nuances of wh=
en a nonce is fine and when PKCE should be used is impossible without in-dep=
th knowledge of the flows and their properties. Misunderstandings will cause=
 security vulnerabilities, which can easily be avoided.
>>=20
>> Since OAuth 2.1 is a separate spec, I don=E2=80=99t really see a problem w=
ith existing code not being compliant. They support OAuth 2.0, and if they w=
ant to be OAuth 2.1 compliant, they add PKCE. If I=E2=80=99m not mistaken, o=
ther requirements of OAuth 2.1 would also clash with existing deployments (e=
.g., using non-exact redirect URIs).
>>=20
>> I believe that optimizing for making OAuth 2.1 easier to understand will y=
ield the highest return.
>>=20
>> Philippe
>>=20
>>=20
>>> On 8 May 2020, at 03:42, Mike Jones  wrote:
>>>=20
>>> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  You=
=E2=80=99re concerned about =E2=80=9Cthe amount of explanation this will tak=
e=E2=80=9D.  That=E2=80=99s optimizing for spec simplicity =E2=80=93 a goal t=
hat I do understand.  However, by writing these few sentences or paragraphs,=
 we=E2=80=99ll make it clear to developers that hundreds or thousands of dep=
loyed OpenID Connect RPs won=E2=80=99t have to change their deployments.  Th=
at=E2=80=99s optimizing for interoperability and minimizing the burden on de=
velopers, which are far more important.
>>> =20
>>> As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have very d=
ifferent ramifications on interoperability=E2=80=9D.
>>> =20
>>> Even if you=E2=80=99re optimizing for writing, taking a minimally invasi=
ve protocol change approach will optimize that, overall.  If we proceed as y=
ou=E2=80=99re suggesting, a huge amount of writing will occur on StackOverfl=
ow, Medium, SlashDot, blogs, and other developer forums, where confused deve=
lopers will ask =E2=80=9CWhy do I have to change my deployed code?=E2=80=9D w=
ith the answers being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99=
s no need to change your deployed code.=E2=80=9D
>>> =20
>>> I=E2=80=99d gladly write a few sentences in our new specs now to prevent=
 ongoing confusion and interop problems that would otherwise result.  Let me=
 know when you=E2=80=99re ready to incorporate them into the spec text.
>>> =20
>>>                                                        -- Mike
>>> =20
>>> From: Aaron Parecki =20
>>> Sent: Thursday, May 7, 2020 4:39 PM
>>> To: Dick Hardt 
>>> Cc: OAuth WG ; Torsten Lodderstedt ; Mike Jones 
>>> Subject: Re: OAuth 2.1 - require PKCE?
>>> =20
>>> Backing up a step or two, there's another point here that I think has be=
en missed in these discussions.
>>> =20
>>> PKCE solves two problems: stolen authorization codes for public clients,=
 and authorization code injection for all clients. We've only been talking a=
bout authorization code injection on the list so far. The quoted section of t=
he security BCP (4.5.3) which says clients can do PKCE or use the nonce, is o=
nly talking about preventing authorization code injection.
>>> =20
>>> The nonce parameter solves authorization code injection if the client re=
quests an ID token. Public clients using the nonce parameter are still susce=
ptible to stolen authorization codes so they still need to do PKCE as well.
>>> =20
>>> The only case where OpenID Connect clients don't benefit from PKCE is if=
 they are also confidential clients. Public client OIDC clients still need t=
o do PKCE even if they check the nonce.
>>> =20
>>> OpenID Connect servers working with confidential clients still benefit f=
rom PKCE because they can then enforce the authorization code injection prot=
ection server-side rather than cross their fingers that clients implemented t=
he nonce check properly.
>>> =20
>>> I really don't think it's worth the amount of explanation this will take=
 in the future to write an exception into OAuth 2.1 or the Security BCP for o=
nly some types of OpenID Connect clients when all clients would benefit from=
 PKCE anyway.
>>> =20
>>> Aaron
>>> =20
>>> =20
>>> =20
>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:=

>>> Hello!
>>> =20
>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is be=
st practice for OAuth 2.0. It is not common in OpenID Connect servers as the=
 nonce solves some of the issues that PKCE protects against. We think that m=
ost OpenID Connect implementations also support OAuth 2.0, and hence have su=
pport for PKCE if following best practices.
>>> =20
>>> The advantages or requiring PKCE are:
>>> =20
>>> - a simpler programming model across all OAuth applications and profiles=
 as they all use PKCE
>>> =20
>>> - reduced attack surface when using  S256 as a fingerprint of the verifi=
er is sent through the browser instead of the clear text value
>>> =20
>>> - enforcement by AS not client - makes it easier to handle for client de=
velopers and AS can ensure the check is conducted
>>> =20
>>> What are disadvantages besides the potential impact to OpenID Connect de=
ployments? How significant is that impact?
>>> =20
>>> Dick, Aaron, and Torsten
>>> =20
>>> =E1=90=A7
>>> _______________________________________________
>>> 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-2AFEB999-6A9D-4159-9BA2-0ACC741106E4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

We are not discussing anything new here. We=
 are discussing adoption of best practice. 

The disc=
onnect appears to be that one dependent standard=E2=80=99s =E2=80=9Ctypical=E2=
=80=9D use (nonces) does not have the ietf consensus as best practice. =


This lack of consensus needs to be resolved. =


Phil

On May 8, 2020, at 12:37 PM, Dick Hardt <dick.har=
dt@gmail.com> wrote:

=

=EF=BB=BF
FYI: An objective of OAuth 2.1 is=
 not to introduce anything new -- it is OAuth 2.0 with best practices. =


O=
n Thu, May 7, 2020 at 10:36 PM Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote=
:
=46rom working with a lot of developers on underst=
anding OAuth 2.0 and OIDC, I definitely vote for simplicity. Understanding t=
he subtle nuances of when a nonce is fine and when PKCE should be used is im=
possible without in-depth knowledge of the flows and their properties. Misun=
derstandings will cause security vulnerabilities, which can easily be avoide=
d.

Since OAuth 2.1 is a separate spec, I don=E2=80=99t re=
ally see a problem with existing code not being compliant. They support OAut=
h 2.0, and if they want to be OAuth 2.1 compliant, they add PKCE. If I=E2=80=
=99m not mistaken, other requirements of OAuth 2.1 would also clash with exi=
sting deployments (e.g., using non-exact redirect URIs).

I believe that optimizing for making OAuth 2.1 easier to understand wi=
ll yield the highest return.

Philippe



On 8 May 2020, at 03:42, Mike Jones &=
lt;Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
=

Aaron=
, I believe you=E2=80=99re trying to optimize the wrong thing.  You=E2=80=
=99re concerned about =E2=80=9Cthe amount of explanation this will ta=
ke=E2=80=9D.  That=E2=80=99s optimiz=
ing for spec simplicity =E2=80=93 a goal that I do understand.  However=
, by writing these few sentences or paragraphs, we=E2=80=99ll make it clear t=
o developers that hundreds or thousands of deployed OpenID Connect RPs won=E2=
=80=99t have to change their deployments.  That=E2=80=99s optimizing fo=
r interoperability and minimizing the burden on developers, which are far mo=
re important.
 
As Brian Campbell wrote, =E2=80=9CThey are not equivalent an=
d have very different ramifications on interoperability=E2=80=9D.
 
Even if you=E2=80=99re optimizing for writing, taking a mi=
nimally invasive protocol change approach will optimize that, overall. =
 If we proceed as you=E2=80=99re suggesting, a huge amount of writing will o=
ccur on StackOverflow, Medium, SlashDot, blogs, and other developer forums, w=
here confused developers will ask =E2=80=9CWhy do I have to change my deploy=
ed code?=E2=80=9D with the answers being =E2=80=9CDespite what the 2.1 spec s=
ays, there=E2=80=99s no need to change your deployed code.=E2=80=9D
 <=
u>
I=E2=80=99d g=
ladly write a few sentences in our new specs now to prevent ongoing confusio=
n and interop problems that would otherwise result.  Let me know when y=
ou=E2=80=99re ready to incorporate them into the spec text.
 
   &nb=
sp;            &=
nbsp;            =
;            &nb=
sp;             -=
- Mike
 
From: Aaron Parecki <aaron@parecki.com> 
Sent:&=
nbsp;Thursday, May 7, 2020 4:39 PM
To: Di=
ck Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@ietf..o=
rg>; Torsten Lodderstedt <torsten=
@lodderstedt.net>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Re=
: OAuth 2.1 - require PKCE?
 <=
u>
Backing up a step or two, there's another poi=
nt here that I think has been missed in these discussions.
 
PKCE solves tw=
o problems: stolen authorization codes for public clients, and authorization=
 code injection for all clients. We've only been talking about authorization=
 code injection on the list so far. The quoted section of the security BCP (=
4.5.3) which says clients can do PKCE or use the nonce, is only talking abou=
t preventing authorization code injection.
 
The nonce parameter solv=
es authorization code injection if the client requests an ID token. Public c=
lients using the nonce parameter are still susceptible to stolen authorizati=
on codes so they still need to do PKCE as well.
 
The only case where=
 OpenID Connect clients don't benefit from PKCE is if they are also confiden=
tial clients. Public client OIDC clients still need to do PKCE even if they c=
heck the nonce.
 <=
/div>
OpenID Connect servers working with confidential cl=
ients still benefit from PKCE because they can then enforce the authorizatio=
n code injection protection server-side rather than cross their fi=
ngers that clients implemented the nonce check properly.
=

 
I really d=
on't think it's worth the amount of explanation this will take in the future=
 to write an exception into OAuth 2.1 or the Security BCP for only some type=
s of OpenID Connect clients when all clients would benefit from PKCE anyway.=

 
Aaron
 <=
/div>
 
<=
/u> 
On Wed, May 6, 2020 at 10:48 AM Dic=
k Hardt <dick.hardt@gmail.com> wrote:=

Hello!
 
W=
e would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best pr=
actice for OAuth 2.0. It is not common in OpenID Connect servers as the nonc=
e solves some of the issues that PKCE protects against. We think that most O=
penID Connect implementations also support OAuth 2.0, and hence have su=
pport for PKCE if following best practices.
 
The advantages or requi=
ring PKCE are:
 
- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE
 
- reduced attack surface w=
hen using  S256 as a fingerprint of the verifier is sent through the br=
owser instead of the clear text value
 
- enforcement by AS not clien=
t - makes it easier to handle for client developers and AS can ensure the ch=
eck is conducted
 <=
/div>
What are disadvantages besides the potential impact=
 to OpenID Connect deployments? How significant is that impact?
 
Dick=
, Aaron, and Torsten
 <=
/u>
=E1=90=A7
_______________________________________________
OAuth mailing list<=
/span>
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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

--Apple-Mail-2AFEB999-6A9D-4159-9BA2-0ACC741106E4--


From nobody Fri May  8 12:49:14 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F473A0E09 for ; Fri,  8 May 2020 12:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtBUVzoDb4BX for ; Fri,  8 May 2020 12:49:03 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583753A0C1C for ; Fri,  8 May 2020 12:49:03 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id s9so2374778lfp.1 for ; Fri, 08 May 2020 12:49:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7Kpet99hAkJC3xO+huHDbjQMqDWToH4tnX0rF7UUeM=; b=Xmoc+OobzonQmXRa7gDhccFuZqvt0N7J3ZLd0QlLvSwM7VYXIsVR/wSmX6r5O312hD Zh3wy//H9ZgmH2zqSioGMCAz7LClCrtOT5BYLySnRh02QHjgY9RkniEDODP+47Ft6B8y awGLl6r37v4rwReYX4kdoML/8GLa3NK+xdC+fT9y3b3q2WtqjmSG5QX5ts0pQjKN3iUQ +MmfE/6h9FeOrgUswZ+cBB3CNkftG7qAwzD7nPZzHD0WCmAEO4g22Ui4XS0lHSG2fVsj +aN5TUDHTw6rdsTPjPJWDrZjNpFukiWnxJsoiGpAsW7YLrkaUekQiB173NKSgAcbuwGc n8LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N7Kpet99hAkJC3xO+huHDbjQMqDWToH4tnX0rF7UUeM=; b=noDgZMo+jYPu6yzLFrZUDjghIogzY17pOrxjU67/bORi5+C1UxP75Wc75ZxnkSdW3s XAEbovTJ+KgWMEgiUs3XH+OQ5F75RQvxHmO6P2QbiQ+xfCDzmspcWGyQjiGnycj5wH43 PKoojxruVXQSB35BIElGcxc8X6mXT++XFReukwZstg+B5yhjC70SaMLhgWzcs4ycqlKE 6/MdfW3NAG5Y1lzl9QyKrWVZaXWslx6lTgk/TPHRDGY/Y6rqdS1w4NjLNAw2/fVx1CxM lqbl5K/w6sWhT7fn2rebVAJRA0M0X0I0tCj3wRBaXJnZGY42KFBnHuJa/ItlvzTB/fta dHCA==
X-Gm-Message-State: AOAM531dMq6vMLCp0vGn16PTq0cheBEdld7SeJJ9BrFBG7Y7sLDd99op TEvKRp23ehoeG1k9qC7hyDO32J3l0EEKgKsdXSskteHX
X-Google-Smtp-Source: ABdhPJwOuwsFQGRWglAoR4J7BTA9NzJ5SMRe5JQrtTQ6sUBcp++Jdctba8Yu6/hfsNe06KcLewY6ew88JJZ3ggzsOFY=
X-Received: by 2002:a19:80ca:: with SMTP id b193mr2601366lfd.7.1588967341293;  Fri, 08 May 2020 12:49:01 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 8 May 2020 12:48:35 -0700
Message-ID: 
To: Aaron Parecki 
Cc: Philippe De Ryck ,  Mike Jones , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000f003ac05a5284955"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 19:49:10 -0000

--000000000000f003ac05a5284955
Content-Type: text/plain; charset="UTF-8"

On Fri, May 8, 2020 at 12:42 PM Aaron Parecki  wrote:

> > FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is
> OAuth 2.0 with best practices.
>
> The line there is kind of fuzzy. The objective is not to introduce new
> concepts, however there are some changes defined that are "breaking
> changes" from plain OAuth 2.0, because those things being removed were not
> best practices for example.
>

I was clarifying that OAuth 2.1 is not introducing new features, for eg.
the WebSocket support question.

I think we can say that:

An OAuth 2.0 compliant deployment following "best practices" is also an
OAuth 2.1 compliant deployment.

This thread is a discussion of what "best practices" is.

--000000000000f003ac05a5284955
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, May 8, 2020 at 12:42 PM Aaron=
 Parecki <aaron@parecki.com>=
 wrote:
> FYI: An objective of OAuth 2.1 is not to introduce anything n=
ew -- it is OAuth 2.0 with best practices.=C2=A0

The lin=
e there is kind of fuzzy. The objective is not to introduce new concepts, h=
owever there are some changes defined that are "breaking changes"=
 from plain OAuth 2.0, because those things being removed were not best pra=
ctices for example.=C2=A0

I was=
 clarifying that OAuth 2.1 is not introducing new features, for eg. the Web=
Socket support question.

I think we=C2=A0can say t=
hat:

An OAuth 2.0 compliant deployment following &=
quot;best practices" is also an OAuth 2.1 compliant deployment.
<=
div>
This thread is a discussion of what "best practices=
" is.



--000000000000f003ac05a5284955--


From nobody Fri May  8 13:27:17 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E813A0EAE for ; Fri,  8 May 2020 13:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s29-2ethZ4Ty for ; Fri,  8 May 2020 13:25:23 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640127.outbound.protection.outlook.com [40.107.64.127]) (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 274B03A0EB6 for ; Fri,  8 May 2020 13:24:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T0aJBuK58idLkbd+yrYFVitKyoFlvXrlAlhqPZwGluknKpls/mm4K8AAf+zqjyFObO34w6EM+6dimfNxJI5/ne7nVEkuo5f4Yk1fYz5jN/BLQxfuEFuPM533LdRn4lCUeZP5H9OqW+J4ulGzs617gR+jnVzhsH1LzV23k/J2abL+8VeEh36/gzViATfcno6Rm99GYeBPMuk7Zea2FQvJv3Ap8iD3S47UJWpghT6oXIlRjBpDNuXrQium5TJX2xlZn/iCVj6oE4EvdUvDubjOO5ve7+U2TIimeQejF6dHbqiQndNupjeFqsoVCz7GbcSnRb8/Wh/dFw1gZbZAoeNv9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FgUpHRPABASC/2zKclqPzc9uukMC6y0Xhg6Ws1TKhd4=; b=mTYIRalh9VTTzHYCyL0T7xWrgq6RUacoLAgPwonUzqgc/x2/msnbOd0aJqHBIRlnWVITxtQCJ9aXAkhRbeDf6UcRXIQQEjvV2f8n68Q9DvJUUp7sbTy5XwGcgw9JPHP5qTWeEwUyVPHN+d93eaZ8Wr0LwqaGdBECEObrNfP5SaHEidOsobSqJ6RSqQeZtPZiRxlSr/6YCmzo3dd8U9CJmL8JucGvbtg+GophYz/lYnLpQcVTYelUlNV7cCwd2Hhm2w4EdRTlapbbM5jnrp+3BhoNP/iHfBaTdRLw9Eauy7Lkpglxkeiy6qQLuRRfyO85+2cfdXdIJ85RAnxQRJQu0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FgUpHRPABASC/2zKclqPzc9uukMC6y0Xhg6Ws1TKhd4=; b=daDcWhBcBghuxvYpaAoA2uur51VZx5hdFlQCt98FAHP3xuzR0jNcRXQxfKa+0JBKerqnRjZBObJKvQph3zrhI0+qw6wnXJoFojE7HBUOA8vk/dZDMMrS6lvF9MAWKadnAVzDpwvwj16ahexal2xlfrWCCi64U5Ey1iakOWc4TD0=
Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0339.namprd00.prod.outlook.com (2603:10b6:207:1f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3015.0; Fri, 8 May 2020 20:24:50 +0000
Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073%7]) with mapi id 15.20.3025.000; Fri, 8 May 2020 20:24:50 +0000
From: Mike Jones 
To: Phillip Hunt , Dick Hardt 
CC: Philippe De Ryck , OAuth WG 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYldrhR4VOCGpg6R6+hy9/8Vn1Hdg==
Date: Fri, 8 May 2020 20:24:50 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=20e26554-c52d-4339-a3cd-000096c181ac; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-08T20:21:07Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: independentid.com; dkim=none (message not signed) header.d=none;independentid.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 00cb799b-653b-4bcb-91f6-08d7f38ddc0d
x-ms-traffictypediagnostic: BL0PR00MB0339:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:4941;
x-forefront-prvs: 039735BC4E
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: W9K4rsp9PhYiQjsXptdElJmP/63zzJzcmH/zbAI/UQUkuvE5nBbpLxm+44F93buMg4/C5sH/4aOjpg4ZdoE2Zs8rRADC1eIVXZZKx317FhC/xKTV8s4jG13MpuCvXJ7WmTRQ8kvd0mRLPfkTQoiNQXeD04uqSVYgYrC8lTgCYnv+z7jFZqFvthF3ES47tOlcc4WLGyN0OmhAPvYu7KcsNbp4ttTIGDtVrXLnPj2WA8jcMRB7REDYAv+qPd9xUsK6pD8LArUNrinq4yAGiQgU0WjuNriSHeX9LVWwK1L+DU+8fafRkDqnA7p9oBbgplMP74HOvJQQ9zHAUDla/nML6ua+RtafayRMViJ/wAT2kJtmGMGYlg6BAJPJichYJ+IIMmVinRxTZaorOXN3N71rQ9ShBdyOeb6V1BeXqANYEA52bJrObIZKnMe4Ytd4ovvyUjXvyp04+82AliWXWKcfeeaCPyFp4NjrSErB51f2+tjCFG8ldmhoqqoc5cm7iHPMMCXi3vumkF4Su+GnXJTdLQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(396003)(39860400002)(366004)(346002)(136003)(33430700001)(186003)(8936002)(9686003)(33656002)(166002)(316002)(26005)(2906002)(4326008)(66574014)(5660300002)(76236002)(8676002)(71200400001)(55016002)(966005)(110136005)(54906003)(53546011)(478600001)(64756008)(8990500004)(66556008)(6506007)(76116006)(66446008)(86362001)(7696005)(83320400001)(83310400001)(83300400001)(82960400001)(66946007)(10290500003)(52536014)(33440700001)(82950400001)(66476007)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: Jm3vuB0ZSyT0Se2vbjJDsKaIZJePNDs7FLduK9evTXrRrOSooXCKG4jKaXpju3fOK/qc4+Hx3JvO18o50n42Apw7l14P/DCzMRtwOoqgWef4lBnvw08+dHhr0Yg38gaVtgVip8NH0Q4M72siMWTjOYa6l04m0RiphRChvzdJtDeXqkyi23kaFKltc82OnxfK4XM+txrwisMMbuYV05uVEkGyEtSQ6fdUKpGZXWH2zeE4Q68x0TqCLZFXyRqAcwa9HtIGE+r+pau6nGy6xJGUv5FpXEdh+Rtc7Pnd4bJuKF1geWEAsu088SmIQfO9sIXFGdsKfQdMEyNZcGI/briggop/UeueSj6sD1TP7yGyGv/EARr+uVV8GHKvqTcgD94FGjuCIh+IV+B6ppzvz+qowCT2BhzFigR51CnY5nqkkN0te/2i3H5LnEIIb0gKVaUWjiY3l9bwLXC/LpHbBPjhKCzvIh2owE+EhI7TwK++/KM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688255B6AE8C5369D26A0B5F5A20MN2PR00MB0688namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00cb799b-653b-4bcb-91f6-08d7f38ddc0d
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 20:24:50.2267 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wxgyqGsBz80+Pfenvvzv1zHyZUUuggbrs74fGRiyIP7VzWreBhsGI3ogqLtNmK56YXNZuT34LkbNrjD1JDT9tw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0339
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 20:25:37 -0000

--_000_MN2PR00MB0688255B6AE8C5369D26A0B5F5A20MN2PR00MB0688namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWN0dWFsbHksIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgdGhlIFNlY3VyaXR5IEJDUCBzZWN0aW9u
IGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5
LXRvcGljcy0xNSNzZWN0aW9uLTIuMS4xLCB3aGljaCBoYXMgZ29uZSB0aHJvdWdoIFdHTEMsIGlu
Y2x1ZGVzIHRoZSB1c2Ugb2Yg4oCcbm9uY2XigJ0gdG8gcHJldmVudCBhdXRob3JpemF0aW9uIGNv
ZGUgaW5qZWN0aW9uIGFzIGEgYmVzdCBwcmFjdGljZS4gIFRoYXTigJlzIGFscmVhZHkgYSBwcmV0
dHkgc3Ryb25nIHN0YW1wIG9mIGFwcHJvdmFsIGJ5IHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLg0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LS0gTWlrZQ0KDQpGcm9tOiBQaGlsbGlwIEh1bnQgPHBoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNv
bT4NClNlbnQ6IEZyaWRheSwgTWF5IDgsIDIwMjAgMTI6NDUgUE0NClRvOiBEaWNrIEhhcmR0IDxk
aWNrLmhhcmR0QGdtYWlsLmNvbT4NCkNjOiBQaGlsaXBwZSBEZSBSeWNrIDxwaGlsaXBwZUBwcmFn
bWF0aWN3ZWJzZWN1cml0eS5jb20+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb20+OyBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/DQoNCldlIGFyZSBub3QgZGlzY3Vzc2luZyBhbnl0
aGluZyBuZXcgaGVyZS4gV2UgYXJlIGRpc2N1c3NpbmcgYWRvcHRpb24gb2YgYmVzdCBwcmFjdGlj
ZS4NCg0KVGhlIGRpc2Nvbm5lY3QgYXBwZWFycyB0byBiZSB0aGF0IG9uZSBkZXBlbmRlbnQgc3Rh
bmRhcmTigJlzIOKAnHR5cGljYWzigJ0gdXNlIChub25jZXMpIGRvZXMgbm90IGhhdmUgdGhlIGll
dGYgY29uc2Vuc3VzIGFzIGJlc3QgcHJhY3RpY2UuDQoNClRoaXMgbGFjayBvZiBjb25zZW5zdXMg
bmVlZHMgdG8gYmUgcmVzb2x2ZWQuDQoNClBoaWwNCg0KDQpPbiBNYXkgOCwgMjAyMCwgYXQgMTI6
MzcgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0
QGdtYWlsLmNvbT4+IHdyb3RlOg0K77u/DQpGWUk6IEFuIG9iamVjdGl2ZSBvZiBPQXV0aCAyLjEg
aXMgbm90IHRvIGludHJvZHVjZSBhbnl0aGluZyBuZXcgLS0gaXQgaXMgT0F1dGggMi4wIHdpdGgg
YmVzdCBwcmFjdGljZXMuDQoNCk9uIFRodSwgTWF5IDcsIDIwMjAgYXQgMTA6MzYgUE0gUGhpbGlw
cGUgRGUgUnljayA8cGhpbGlwcGVAcHJhZ21hdGljd2Vic2VjdXJpdHkuY29tPG1haWx0bzpwaGls
aXBwZUBwcmFnbWF0aWN3ZWJzZWN1cml0eS5jb20+PiB3cm90ZToNCkZyb20gd29ya2luZyB3aXRo
IGEgbG90IG9mIGRldmVsb3BlcnMgb24gdW5kZXJzdGFuZGluZyBPQXV0aCAyLjAgYW5kIE9JREMs
IEkgZGVmaW5pdGVseSB2b3RlIGZvciBzaW1wbGljaXR5LiBVbmRlcnN0YW5kaW5nIHRoZSBzdWJ0
bGUgbnVhbmNlcyBvZiB3aGVuIGEgbm9uY2UgaXMgZmluZSBhbmQgd2hlbiBQS0NFIHNob3VsZCBi
ZSB1c2VkIGlzIGltcG9zc2libGUgd2l0aG91dCBpbi1kZXB0aCBrbm93bGVkZ2Ugb2YgdGhlIGZs
b3dzIGFuZCB0aGVpciBwcm9wZXJ0aWVzLiBNaXN1bmRlcnN0YW5kaW5ncyB3aWxsIGNhdXNlIHNl
Y3VyaXR5IHZ1bG5lcmFiaWxpdGllcywgd2hpY2ggY2FuIGVhc2lseSBiZSBhdm9pZGVkLg0KDQpT
aW5jZSBPQXV0aCAyLjEgaXMgYSBzZXBhcmF0ZSBzcGVjLCBJIGRvbuKAmXQgcmVhbGx5IHNlZSBh
IHByb2JsZW0gd2l0aCBleGlzdGluZyBjb2RlIG5vdCBiZWluZyBjb21wbGlhbnQuIFRoZXkgc3Vw
cG9ydCBPQXV0aCAyLjAsIGFuZCBpZiB0aGV5IHdhbnQgdG8gYmUgT0F1dGggMi4xIGNvbXBsaWFu
dCwgdGhleSBhZGQgUEtDRS4gSWYgSeKAmW0gbm90IG1pc3Rha2VuLCBvdGhlciByZXF1aXJlbWVu
dHMgb2YgT0F1dGggMi4xIHdvdWxkIGFsc28gY2xhc2ggd2l0aCBleGlzdGluZyBkZXBsb3ltZW50
cyAoZS5nLiwgdXNpbmcgbm9uLWV4YWN0IHJlZGlyZWN0IFVSSXMpLg0KDQpJIGJlbGlldmUgdGhh
dCBvcHRpbWl6aW5nIGZvciBtYWtpbmcgT0F1dGggMi4xIGVhc2llciB0byB1bmRlcnN0YW5kIHdp
bGwgeWllbGQgdGhlIGhpZ2hlc3QgcmV0dXJuLg0KDQpQaGlsaXBwZQ0KDQoNCg0KT24gOCBNYXkg
MjAyMCwgYXQgMDM6NDIsIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29t
QGRtYXJjLmlldGYub3JnPG1haWx0bzpNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpBYXJvbiwgSSBiZWxpZXZlIHlvdeKAmXJlIHRyeWluZyB0
byBvcHRpbWl6ZSB0aGUgd3JvbmcgdGhpbmcuICBZb3XigJlyZSBjb25jZXJuZWQgYWJvdXQg4oCc
dGhlIGFtb3VudCBvZiBleHBsYW5hdGlvbiB0aGlzIHdpbGwgdGFrZeKAnS4gIFRoYXTigJlzIG9w
dGltaXppbmcgZm9yIHNwZWMgc2ltcGxpY2l0eSDigJMgYSBnb2FsIHRoYXQgSSBkbyB1bmRlcnN0
YW5kLiAgSG93ZXZlciwgYnkgd3JpdGluZyB0aGVzZSBmZXcgc2VudGVuY2VzIG9yIHBhcmFncmFw
aHMsIHdl4oCZbGwgbWFrZSBpdCBjbGVhciB0byBkZXZlbG9wZXJzIHRoYXQgaHVuZHJlZHMgb3Ig
dGhvdXNhbmRzIG9mIGRlcGxveWVkIE9wZW5JRCBDb25uZWN0IFJQcyB3b27igJl0IGhhdmUgdG8g
Y2hhbmdlIHRoZWlyIGRlcGxveW1lbnRzLiAgVGhhdOKAmXMgb3B0aW1pemluZyBmb3IgaW50ZXJv
cGVyYWJpbGl0eSBhbmQgbWluaW1pemluZyB0aGUgYnVyZGVuIG9uIGRldmVsb3BlcnMsIHdoaWNo
IGFyZSBmYXIgbW9yZSBpbXBvcnRhbnQuDQoNCkFzIEJyaWFuIENhbXBiZWxsIHdyb3RlLCDigJxU
aGV5IGFyZSBub3QgZXF1aXZhbGVudCBhbmQgaGF2ZSB2ZXJ5IGRpZmZlcmVudCByYW1pZmljYXRp
b25zIG9uIGludGVyb3BlcmFiaWxpdHnigJ0uDQoNCkV2ZW4gaWYgeW914oCZcmUgb3B0aW1pemlu
ZyBmb3Igd3JpdGluZywgdGFraW5nIGEgbWluaW1hbGx5IGludmFzaXZlIHByb3RvY29sIGNoYW5n
ZSBhcHByb2FjaCB3aWxsIG9wdGltaXplIHRoYXQsIG92ZXJhbGwuICBJZiB3ZSBwcm9jZWVkIGFz
IHlvdeKAmXJlIHN1Z2dlc3RpbmcsIGEgaHVnZSBhbW91bnQgb2Ygd3JpdGluZyB3aWxsIG9jY3Vy
IG9uIFN0YWNrT3ZlcmZsb3csIE1lZGl1bSwgU2xhc2hEb3QsIGJsb2dzLCBhbmQgb3RoZXIgZGV2
ZWxvcGVyIGZvcnVtcywgd2hlcmUgY29uZnVzZWQgZGV2ZWxvcGVycyB3aWxsIGFzayDigJxXaHkg
ZG8gSSBoYXZlIHRvIGNoYW5nZSBteSBkZXBsb3llZCBjb2RlP+KAnSB3aXRoIHRoZSBhbnN3ZXJz
IGJlaW5nIOKAnERlc3BpdGUgd2hhdCB0aGUgMi4xIHNwZWMgc2F5cywgdGhlcmXigJlzIG5vIG5l
ZWQgdG8gY2hhbmdlIHlvdXIgZGVwbG95ZWQgY29kZS7igJ0NCg0KSeKAmWQgZ2xhZGx5IHdyaXRl
IGEgZmV3IHNlbnRlbmNlcyBpbiBvdXIgbmV3IHNwZWNzIG5vdyB0byBwcmV2ZW50IG9uZ29pbmcg
Y29uZnVzaW9uIGFuZCBpbnRlcm9wIHByb2JsZW1zIHRoYXQgd291bGQgb3RoZXJ3aXNlIHJlc3Vs
dC4gIExldCBtZSBrbm93IHdoZW4geW914oCZcmUgcmVhZHkgdG8gaW5jb3Jwb3JhdGUgdGhlbSBp
bnRvIHRoZSBzcGVjIHRleHQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEFhcm9uIFBhcmVja2kgPGFhcm9u
QHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+DQpTZW50OiBUaHVyc2RheSwg
TWF5IDcsIDIwMjAgNDozOSBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29t
PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpDYzogT0F1dGggV0cgPG9hdXRoQGlldGYu
Lm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PjsgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rl
bkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQuLm5ldD4+OyBNaWtl
IEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNA
bWljcm9zb2Z0LmNvbT4+DQpTdWJqZWN0OiBSZTogT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPw0K
DQpCYWNraW5nIHVwIGEgc3RlcCBvciB0d28sIHRoZXJlJ3MgYW5vdGhlciBwb2ludCBoZXJlIHRo
YXQgSSB0aGluayBoYXMgYmVlbiBtaXNzZWQgaW4gdGhlc2UgZGlzY3Vzc2lvbnMuDQoNClBLQ0Ug
c29sdmVzIHR3byBwcm9ibGVtczogc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgZm9yIHB1Ymxp
YyBjbGllbnRzLCBhbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBmb3IgYWxsIGNsaWVu
dHMuIFdlJ3ZlIG9ubHkgYmVlbiB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRpb24gY29kZSBpbmpl
Y3Rpb24gb24gdGhlIGxpc3Qgc28gZmFyLiBUaGUgcXVvdGVkIHNlY3Rpb24gb2YgdGhlIHNlY3Vy
aXR5IEJDUCAoNC41LjMpIHdoaWNoIHNheXMgY2xpZW50cyBjYW4gZG8gUEtDRSBvciB1c2UgdGhl
IG5vbmNlLCBpcyBvbmx5IHRhbGtpbmcgYWJvdXQgcHJldmVudGluZyBhdXRob3JpemF0aW9uIGNv
ZGUgaW5qZWN0aW9uLg0KDQpUaGUgbm9uY2UgcGFyYW1ldGVyIHNvbHZlcyBhdXRob3JpemF0aW9u
IGNvZGUgaW5qZWN0aW9uIGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gSUQgdG9rZW4uIFB1Ymxp
YyBjbGllbnRzIHVzaW5nIHRoZSBub25jZSBwYXJhbWV0ZXIgYXJlIHN0aWxsIHN1c2NlcHRpYmxl
IHRvIHN0b2xlbiBhdXRob3JpemF0aW9uIGNvZGVzIHNvIHRoZXkgc3RpbGwgbmVlZCB0byBkbyBQ
S0NFIGFzIHdlbGwuDQoNClRoZSBvbmx5IGNhc2Ugd2hlcmUgT3BlbklEIENvbm5lY3QgY2xpZW50
cyBkb24ndCBiZW5lZml0IGZyb20gUEtDRSBpcyBpZiB0aGV5IGFyZSBhbHNvIGNvbmZpZGVudGlh
bCBjbGllbnRzLiBQdWJsaWMgY2xpZW50IE9JREMgY2xpZW50cyBzdGlsbCBuZWVkIHRvIGRvIFBL
Q0UgZXZlbiBpZiB0aGV5IGNoZWNrIHRoZSBub25jZS4NCg0KT3BlbklEIENvbm5lY3Qgc2VydmVy
cyB3b3JraW5nIHdpdGggY29uZmlkZW50aWFsIGNsaWVudHMgc3RpbGwgYmVuZWZpdCBmcm9tIFBL
Q0UgYmVjYXVzZSB0aGV5IGNhbiB0aGVuIGVuZm9yY2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBp
bmplY3Rpb24gcHJvdGVjdGlvbiBzZXJ2ZXItc2lkZSByYXRoZXIgdGhhbiBjcm9zcyB0aGVpciBm
aW5nZXJzIHRoYXQgY2xpZW50cyBpbXBsZW1lbnRlZCB0aGUgbm9uY2UgY2hlY2sgcHJvcGVybHku
DQoNCkkgcmVhbGx5IGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdGhlIGFtb3VudCBvZiBleHBsYW5h
dGlvbiB0aGlzIHdpbGwgdGFrZSBpbiB0aGUgZnV0dXJlIHRvIHdyaXRlIGFuIGV4Y2VwdGlvbiBp
bnRvIE9BdXRoIDIuMSBvciB0aGUgU2VjdXJpdHkgQkNQIGZvciBvbmx5IHNvbWUgdHlwZXMgb2Yg
T3BlbklEIENvbm5lY3QgY2xpZW50cyB3aGVuIGFsbCBjbGllbnRzIHdvdWxkIGJlbmVmaXQgZnJv
bSBQS0NFIGFueXdheS4NCg0KQWFyb24NCg0KDQoNCk9uIFdlZCwgTWF5IDYsIDIwMjAgYXQgMTA6
NDggQU0gRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRA
Z21haWwuY29tPj4gd3JvdGU6DQpIZWxsbyENCg0KV2Ugd291bGQgbGlrZSB0byBoYXZlIFBLQ0Ug
YmUgYSBNVVNUIGluIE9BdXRoIDIuMSBjb2RlIGZsb3dzLiBUaGlzIGlzIGJlc3QgcHJhY3RpY2Ug
Zm9yIE9BdXRoIDIuMC4gSXQgaXMgbm90IGNvbW1vbiBpbiBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJz
IGFzIHRoZSBub25jZSBzb2x2ZXMgc29tZSBvZiB0aGUgaXNzdWVzIHRoYXQgUEtDRSBwcm90ZWN0
cyBhZ2FpbnN0LiBXZSB0aGluayB0aGF0IG1vc3QgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRp
b25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBoZW5jZSBoYXZlIHN1cHBvcnQgZm9yIFBL
Q0UgaWYgZm9sbG93aW5nIGJlc3QgcHJhY3RpY2VzLg0KDQpUaGUgYWR2YW50YWdlcyBvciByZXF1
aXJpbmcgUEtDRSBhcmU6DQoNCi0gYSBzaW1wbGVyIHByb2dyYW1taW5nIG1vZGVsIGFjcm9zcyBh
bGwgT0F1dGggYXBwbGljYXRpb25zIGFuZCBwcm9maWxlcyBhcyB0aGV5IGFsbCB1c2UgUEtDRQ0K
DQotIHJlZHVjZWQgYXR0YWNrIHN1cmZhY2Ugd2hlbiB1c2luZyAgUzI1NiBhcyBhIGZpbmdlcnBy
aW50IG9mIHRoZSB2ZXJpZmllciBpcyBzZW50IHRocm91Z2ggdGhlIGJyb3dzZXIgaW5zdGVhZCBv
ZiB0aGUgY2xlYXIgdGV4dCB2YWx1ZQ0KDQotIGVuZm9yY2VtZW50IGJ5IEFTIG5vdCBjbGllbnQg
LSBtYWtlcyBpdCBlYXNpZXIgdG8gaGFuZGxlIGZvciBjbGllbnQgZGV2ZWxvcGVycyBhbmQgQVMg
Y2FuIGVuc3VyZSB0aGUgY2hlY2sgaXMgY29uZHVjdGVkDQoNCldoYXQgYXJlIGRpc2FkdmFudGFn
ZXMgYmVzaWRlcyB0aGUgcG90ZW50aWFsIGltcGFjdCB0byBPcGVuSUQgQ29ubmVjdCBkZXBsb3lt
ZW50cz8gSG93IHNpZ25pZmljYW50IGlzIHRoYXQgaW1wYWN0Pw0KDQpEaWNrLCBBYXJvbiwgYW5k
IFRvcnN0ZW4NCg0K4ZCnDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt
YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

--_000_MN2PR00MB0688255B6AE8C5369D26A0B5F5A20MN2PR00MB0688namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxl
IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs
DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5B
Y3R1YWxseSwgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgU2VjdXJpdHkgQkNQIHNlY3Rpb24g
YXQNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi0yLjEuMSI+aHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24t
Mi4xLjE8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiwgd2hpY2ggaGFzIGdvbmUgdGhy
b3VnaCBXR0xDLCBpbmNsdWRlcyB0aGUgdXNlIG9mIOKAnG5vbmNl4oCdDQogdG8gcHJldmVudCBh
dXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGFzIGEgYmVzdCBwcmFjdGljZS4mbmJzcDsgVGhh
dOKAmXMgYWxyZWFkeSBhIHByZXR0eSBzdHJvbmcgc3RhbXAgb2YgYXBwcm92YWwgYnkgdGhlIE9B
dXRoIHdvcmtpbmcgZ3JvdXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy
MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu
IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFBoaWxsaXAgSHVu
dCAmbHQ7cGhpbC5odW50QGluZGVwZW5kZW50aWQuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4g
RnJpZGF5LCBNYXkgOCwgMjAyMCAxMjo0NSBQTTxicj4NCjxiPlRvOjwvYj4gRGljayBIYXJkdCAm
bHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQaGlsaXBwZSBEZSBS
eWNrICZsdDtwaGlsaXBwZUBwcmFnbWF0aWN3ZWJzZWN1cml0eS5jb20mZ3Q7OyBNaWtlIEpvbmVz
ICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBPQXV0aCBXRyAmbHQ7b2F1dGhA
aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIu
MSAtIHJlcXVpcmUgUEtDRT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PldlIGFyZSBub3QgZGlzY3Vzc2luZyBhbnl0aGluZyBuZXcgaGVyZS4gV2UgYXJlIGRpc2N1c3Np
bmcgYWRvcHRpb24gb2YgYmVzdCBwcmFjdGljZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkaXNjb25uZWN0IGFwcGVhcnMgdG8gYmUgdGhh
dCBvbmUgZGVwZW5kZW50IHN0YW5kYXJk4oCZcyDigJx0eXBpY2Fs4oCdIHVzZSAobm9uY2VzKSBk
b2VzIG5vdCBoYXZlIHRoZSBpZXRmIGNvbnNlbnN1cyBhcyBiZXN0IHByYWN0aWNlLiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlz
IGxhY2sgb2YgY29uc2Vuc3VzIG5lZWRzIHRvIGJlIHJlc29sdmVkLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K
PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+T24gTWF5IDgsIDIwMjAsIGF0IDEyOjM3IFBNLCBEaWNrIEhhcmR0
ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21h
aWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPu+7vzxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZZSTogQW4gb2JqZWN0aXZlIG9mIE9BdXRoIDIuMSBp
cyBub3QgdG8gaW50cm9kdWNlIGFueXRoaW5nIG5ldyAtLSBpdCBpcyBPQXV0aCAyLjAgd2l0aCBi
ZXN0IHByYWN0aWNlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIFRodSwgTWF5IDcsIDIwMjAgYXQgMTA6MzYgUE0gUGhpbGlwcGUgRGUgUnlj
ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWxpcHBlQHByYWdtYXRpY3dlYnNlY3VyaXR5LmNvbSI+
cGhpbGlwcGVAcHJhZ21hdGljd2Vic2VjdXJpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
RnJvbSB3b3JraW5nIHdpdGggYSBsb3Qgb2YgZGV2ZWxvcGVycyBvbiB1bmRlcnN0YW5kaW5nIE9B
dXRoIDIuMCBhbmQgT0lEQywgSSBkZWZpbml0ZWx5IHZvdGUgZm9yIHNpbXBsaWNpdHkuIFVuZGVy
c3RhbmRpbmcgdGhlIHN1YnRsZSBudWFuY2VzIG9mIHdoZW4gYSBub25jZSBpcyBmaW5lIGFuZCB3
aGVuIFBLQ0Ugc2hvdWxkIGJlIHVzZWQgaXMgaW1wb3NzaWJsZSB3aXRob3V0IGluLWRlcHRoIGtu
b3dsZWRnZQ0KIG9mIHRoZSBmbG93cyBhbmQgdGhlaXIgcHJvcGVydGllcy4gTWlzdW5kZXJzdGFu
ZGluZ3Mgd2lsbCBjYXVzZSBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMsIHdoaWNoIGNhbiBlYXNp
bHkgYmUgYXZvaWRlZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlNpbmNlIE9BdXRoIDIuMSBpcyBhIHNlcGFyYXRlIHNwZWMsIEkgZG9u4oCZdCByZWFsbHkg
c2VlIGEgcHJvYmxlbSB3aXRoIGV4aXN0aW5nIGNvZGUgbm90IGJlaW5nIGNvbXBsaWFudC4gVGhl
eSBzdXBwb3J0IE9BdXRoIDIuMCwgYW5kIGlmIHRoZXkgd2FudCB0byBiZSBPQXV0aCAyLjEgY29t
cGxpYW50LCB0aGV5IGFkZCBQS0NFLiBJZiBJ4oCZbSBub3QgbWlzdGFrZW4sIG90aGVyIHJlcXVp
cmVtZW50cyBvZiBPQXV0aA0KIDIuMSB3b3VsZCBhbHNvIGNsYXNoIHdpdGggZXhpc3RpbmcgZGVw
bG95bWVudHMgKGUuZy4sIHVzaW5nIG5vbi1leGFjdCByZWRpcmVjdCBVUklzKS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRo
YXQgb3B0aW1pemluZyBmb3IgbWFraW5nIE9BdXRoIDIuMSBlYXNpZXIgdG8gdW5kZXJzdGFuZCB3
aWxsIHlpZWxkIHRoZSBoaWdoZXN0IHJldHVybi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbGlwcGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOCBNYXkgMjAyMCwgYXQgMDM6NDIsIE1pa2Ug
Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBk
bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQu
Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi
PkFhcm9uLCBJIGJlbGlldmUgeW914oCZcmUgdHJ5aW5nIHRvIG9wdGltaXplIHRoZSB3cm9uZyB0
aGluZy4mbmJzcDsgWW914oCZcmUgY29uY2VybmVkIGFib3V0IOKAnDwvc3Bhbj50aGUgYW1vdW50
IG9mIGV4cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtlPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi
PuKAnS4mbmJzcDsgVGhhdOKAmXMgb3B0aW1pemluZyBmb3Igc3BlYyBzaW1wbGljaXR5IOKAkyBh
IGdvYWwNCiB0aGF0IEkgZG8gdW5kZXJzdGFuZC4mbmJzcDsgSG93ZXZlciwgYnkgd3JpdGluZyB0
aGVzZSBmZXcgc2VudGVuY2VzIG9yIHBhcmFncmFwaHMsIHdl4oCZbGwgbWFrZSBpdCBjbGVhciB0
byBkZXZlbG9wZXJzIHRoYXQgaHVuZHJlZHMgb3IgdGhvdXNhbmRzIG9mIGRlcGxveWVkIE9wZW5J
RCBDb25uZWN0IFJQcyB3b27igJl0IGhhdmUgdG8gY2hhbmdlIHRoZWlyIGRlcGxveW1lbnRzLiZu
YnNwOyBUaGF04oCZcyBvcHRpbWl6aW5nIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBtaW5pbWl6
aW5nDQogdGhlIGJ1cmRlbiBvbiBkZXZlbG9wZXJzLCB3aGljaCBhcmUgZmFyIG1vcmUgaW1wb3J0
YW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwMjA2MCI+QXMgQnJpYW4gQ2FtcGJlbGwgd3JvdGUsIOKAnDwvc3Bhbj5UaGV5IGFy
ZSBub3QgZXF1aXZhbGVudCBhbmQgaGF2ZSB2ZXJ5IGRpZmZlcmVudCByYW1pZmljYXRpb25zIG9u
IGludGVyb3BlcmFiaWxpdHk8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+4oCdLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2
MCI+RXZlbiBpZiB5b3XigJlyZSBvcHRpbWl6aW5nIGZvciB3cml0aW5nLCB0YWtpbmcgYSBtaW5p
bWFsbHkgaW52YXNpdmUgcHJvdG9jb2wgY2hhbmdlIGFwcHJvYWNoIHdpbGwgb3B0aW1pemUgdGhh
dCwgb3ZlcmFsbC4mbmJzcDsgSWYgd2UgcHJvY2VlZCBhcyB5b3XigJlyZSBzdWdnZXN0aW5nLCBh
IGh1Z2UgYW1vdW50IG9mIHdyaXRpbmcgd2lsbCBvY2N1ciBvbiBTdGFja092ZXJmbG93LA0KIE1l
ZGl1bSwgU2xhc2hEb3QsIGJsb2dzLCBhbmQgb3RoZXIgZGV2ZWxvcGVyIGZvcnVtcywgd2hlcmUg
Y29uZnVzZWQgZGV2ZWxvcGVycyB3aWxsIGFzayDigJxXaHkgZG8gSSBoYXZlIHRvIGNoYW5nZSBt
eSBkZXBsb3llZCBjb2RlP+KAnSB3aXRoIHRoZSBhbnN3ZXJzIGJlaW5nIOKAnERlc3BpdGUgd2hh
dCB0aGUgMi4xIHNwZWMgc2F5cywgdGhlcmXigJlzIG5vIG5lZWQgdG8gY2hhbmdlIHlvdXIgZGVw
bG95ZWQgY29kZS7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPknigJlkIGdsYWRseSB3cml0ZSBhIGZldyBzZW50ZW5j
ZXMgaW4gb3VyIG5ldyBzcGVjcyBub3cgdG8gcHJldmVudCBvbmdvaW5nIGNvbmZ1c2lvbiBhbmQg
aW50ZXJvcCBwcm9ibGVtcyB0aGF0IHdvdWxkIG90aGVyd2lzZSByZXN1bHQuJm5ic3A7IExldCBt
ZSBrbm93IHdoZW4geW914oCZcmUgcmVhZHkgdG8gaW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSBz
cGVjIHRleHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4mbmJzcDtBYXJvbiBQYXJlY2tpICZsdDs8
YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20iIHRhcmdldD0iX2JsYW5rIj5hYXJvbkBw
YXJlY2tpLmNvbTwvYT4mZ3Q7Jm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7VGh1cnNkYXks
IE1heSA3LCAyMDIwIDQ6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7RGljayBIYXJkdCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGlj
ay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4mbmJzcDtPQXV0aCBXRyAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA
aWV0Zi4ub3JnPC9hPiZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0
bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Li5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRl
cnN0ZWR0Lm5ldDwvYT4mZ3Q7OyBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFl
bC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSZTogT0F1dGggMi4x
IC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFja2luZyB1cCBhIHN0ZXAgb3Ig
dHdvLCB0aGVyZSdzIGFub3RoZXIgcG9pbnQgaGVyZSB0aGF0IEkgdGhpbmsgaGFzIGJlZW4gbWlz
c2VkIGluIHRoZXNlIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEtDRSBzb2x2ZXMg
dHdvIHByb2JsZW1zOiBzdG9sZW4gYXV0aG9yaXphdGlvbiBjb2RlcyBmb3IgcHVibGljIGNsaWVu
dHMsIGFuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGZvciBhbGwgY2xpZW50cy4gV2Un
dmUgb25seSBiZWVuIHRhbGtpbmcgYWJvdXQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBv
biB0aGUgbGlzdCBzbyBmYXIuIFRoZSBxdW90ZWQgc2VjdGlvbiBvZiB0aGUgc2VjdXJpdHkNCiBC
Q1AgKDQuNS4zKSB3aGljaCBzYXlzIGNsaWVudHMgY2FuIGRvIFBLQ0Ugb3IgdXNlIHRoZSBub25j
ZSwgaXMgb25seSB0YWxraW5nIGFib3V0IHByZXZlbnRpbmcgYXV0aG9yaXphdGlvbiBjb2RlIGlu
amVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5vbmNlIHBhcmFtZXRlciBz
b2x2ZXMgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBpZiB0aGUgY2xpZW50IHJlcXVlc3Rz
IGFuIElEIHRva2VuLiBQdWJsaWMgY2xpZW50cyB1c2luZyB0aGUgbm9uY2UgcGFyYW1ldGVyIGFy
ZSBzdGlsbCBzdXNjZXB0aWJsZSB0byBzdG9sZW4gYXV0aG9yaXphdGlvbiBjb2RlcyBzbyB0aGV5
IHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgb25seSBjYXNlIHdoZXJlIE9wZW5JRCBDb25uZWN0IGNsaWVudHMgZG9uJ3QgYmVuZWZp
dCBmcm9tIFBLQ0UgaXMgaWYgdGhleSBhcmUgYWxzbyBjb25maWRlbnRpYWwgY2xpZW50cy4gUHVi
bGljIGNsaWVudCBPSURDIGNsaWVudHMgc3RpbGwgbmVlZCB0byBkbyBQS0NFIGV2ZW4gaWYgdGhl
eSBjaGVjayB0aGUgbm9uY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9wZW5JRCBDb25u
ZWN0IHNlcnZlcnMgd29ya2luZyB3aXRoIGNvbmZpZGVudGlhbCBjbGllbnRzIHN0aWxsIGJlbmVm
aXQgZnJvbSBQS0NFIGJlY2F1c2UgdGhleSBjYW4gdGhlbiBlbmZvcmNlIHRoZSBhdXRob3JpemF0
aW9uIGNvZGUgaW5qZWN0aW9uIHByb3RlY3Rpb24gc2VydmVyLXNpZGUmbmJzcDtyYXRoZXImbmJz
cDt0aGFuIGNyb3NzIHRoZWlyIGZpbmdlcnMgdGhhdCBjbGllbnRzIGltcGxlbWVudGVkIHRoZSBu
b25jZSBjaGVjaw0KIHByb3Blcmx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlYWxs
eSBkb24ndCB0aGluayBpdCdzIHdvcnRoIHRoZSBhbW91bnQgb2YgZXhwbGFuYXRpb24gdGhpcyB3
aWxsIHRha2UgaW4gdGhlIGZ1dHVyZSB0byB3cml0ZSBhbiBleGNlcHRpb24gaW50byBPQXV0aCAy
LjEgb3IgdGhlIFNlY3VyaXR5IEJDUCBmb3Igb25seSBzb21lIHR5cGVzIG9mIE9wZW5JRCBDb25u
ZWN0IGNsaWVudHMgd2hlbiBhbGwgY2xpZW50cyB3b3VsZCBiZW5lZml0IGZyb20gUEtDRSBhbnl3
YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1heSA2LCAy
MDIwIGF0IDEwOjQ4IEFNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0
QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y
aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5IZWxsbyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdvdWxkIGxpa2Ug
dG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29kZSBmbG93cy4gVGhpcyBpcyBi
ZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBjb21tb24gaW4gT3BlbklEIENv
bm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUgb2YgdGhlIGlzc3VlcyB0aGF0
IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsgdGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0
DQogaW1wbGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBoZW5jZSZuYnNw
O2hhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhZHZhbnRhZ2VzIG9yIHJlcXVpcmluZyBQS0NFIGFy
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9k
ZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxs
IHVzZSBQS0NFPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gcmVkdWNlZCBhdHRhY2sgc3Vy
ZmFjZSB3aGVuIHVzaW5nJm5ic3A7IFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZp
ZXIgaXMgc2VudCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQg
dmFsdWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBlbmZvcmNlbWVudCBieSBBUyBub3Qg
Y2xpZW50IC0gbWFrZXMgaXQgZWFzaWVyIHRvIGhhbmRsZSBmb3IgY2xpZW50IGRldmVsb3BlcnMg
YW5kIEFTIGNhbiBlbnN1cmUgdGhlIGNoZWNrIGlzIGNvbmR1Y3RlZDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5XaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVudGlhbCBp
bXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2FudCBpcyB0
aGF0IGltcGFjdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGljaywgQWFyb24sIGFuZCBU
b3JzdGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aW1nIGJv
cmRlcj0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgc3R5bGU9IndpZHRoOi4wMTA0aW47aGVpZ2h0
Oi4wMTA0aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNw
b3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9
emVyb2NvbnRlbnQmYW1wO2d1aWQ9NDUyNDM4YmEtZDQyOS00NjU2LWFjZTktYjI4NDc0NGJjMTcx
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8
L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
Pjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0
bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_MN2PR00MB0688255B6AE8C5369D26A0B5F5A20MN2PR00MB0688namp_--


From nobody Fri May  8 15:25:31 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED82D3A0FE1 for ; Fri,  8 May 2020 15:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXiYh63uJ9SB for ; Fri,  8 May 2020 15:25:28 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7904A3A0F98 for ; Fri,  8 May 2020 15:25:28 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id j14so2654649lfg.9 for ; Fri, 08 May 2020 15:25:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=VCFTdjpo8UXutfQacV0qQ1PwuV6wHZk+ixArFb7cRMA=; b=cAVoKLhUTP5wg/o69AN3O3w3bgbS1CBwAY5t6Ga0usONISctKYEkbNBwumRPJXIrOi bf7wPiDMf4Av9+y1fzDzxMQUzTDOQlJ4nHj1nGkN++/G8hNYzF2dm91c8iU7V8NAvp1m j6WvboqXTt5zF1oSVJ0A7MH7zDnrNzuK9x6YCnMlkK1zLmn7Pt/Ko9XddtFAKMXG+Zue DBOdY47b9OltrnGf+zEYcs/DCOzBXHq3AToD9v/HMazSneM1/1UXqWN3LNqlWdIhpI/2 meCrsSrKriC9dwe/cG5h6rTSymg2zwEmNQN39kdo9OGLK2iUOYhBWVyaAoF9KoQLm0g8 ydJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VCFTdjpo8UXutfQacV0qQ1PwuV6wHZk+ixArFb7cRMA=; b=Q0NO58Q/RQyFRX7swSqrgTw5PcZbAWqHt1AbmtXjx28Xk/5Dc4zKe0d7IDnDgn7kfo kjaePpLoAu+1VrCQw1k0q/18mb15yEx5qkNfK83xS95EFTkgn8fkmBlAGwkEtOUbvspW acMH2m1ja5hsV58VZutihtCpXH5nFe1rkIsoFFfWfqqd+5/KKtovEKji2oi3xCn3sprY QR2Qf/zYLPY/H2fw3QQYVClZf0UtSJOGpS5DrQjyn4r4+bU759P3ho68d9WZLgK6Tulg qHqvbKOVvH7QZjYTfbuk2NmPeutkgmMSt4n4wEkO6jPCzKiHrJGoKrL0sL3CH709thJa 0Ieg==
X-Gm-Message-State: AOAM530EOSGs2yHvorgOA7g4Yf0PTLCN27/BnM0+VY4Tj+8Fp0IGVg6G /xDBZtLkAWDyQ/3Fs6lGax3+v++mbUJqvS/iD+VgYOoBYFE=
X-Google-Smtp-Source: ABdhPJyw0QrychhzY0wE+zMlbMByovfeTvgKRI6H4sYQ0suC8AvDGpYBW1u9/uLrL3aSiXFIrzBdPR9TzkgY+zRF3Lo=
X-Received: by 2002:ac2:5212:: with SMTP id a18mr3274058lfl.83.1588976726519;  Fri, 08 May 2020 15:25:26 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Fri, 8 May 2020 18:25:16 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000057336b05a52a7998"
Archived-At: 
Subject: [OAUTH-WG] May 11th Interim Meeting Materials
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 May 2020 22:25:30 -0000

--00000000000057336b05a52a7998
Content-Type: text/plain; charset="UTF-8"

All,

You can find the meeting material for the May 11th meeting at the
following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-08/session/oauth

Regards,
 Rifaat

--00000000000057336b05a52a7998
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

You can find the =
meeting material for the May 11th meeting at the following=C2=A0link:
=


Regards,
=C2=A0Rifa=
at



--00000000000057336b05a52a7998--


From nobody Fri May  8 17:54:21 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510B23A041E for ; Fri,  8 May 2020 17:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3BhY0Amy60W for ; Fri,  8 May 2020 17:54:17 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B1B3A041C for ; Fri,  8 May 2020 17:54:16 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0490s82W005209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 May 2020 20:54:10 -0400
Date: Fri, 8 May 2020 17:54:08 -0700
From: Benjamin Kaduk 
To: Denis 
Cc: Vittorio Bertocci , "oauth@ietf.org" 
Message-ID: <20200509005408.GA27494@kduck.mit.edu>
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 May 2020 00:54:20 -0000

Hi Denis,

Sorry for the slow response.  I had several deadlines this week and
couldn't think much farther ahead than the next one, so my INBOX fell
behind.

On Mon, May 04, 2020 at 12:36:05PM +0200, Denis wrote:
> Hello Benjamin,
> 
> First of all, you don't need to use an aggressive language to state your 
> opinion.

I would appreciate a little more clarity on which language comes across as
"aggressive"; I was trying very hard to stick to what I see as the facts:

- many people are frustrated with these long discussions that continue to
  rehash similar points and involve people having a hard time seeing each
  others' worldview
- you are making proposals for changes to this document that would
  represent drastic changes from previous specifications that are used by
  the current document (and are drastic changes from current practice),
  without acknowledging that they are in fact drastic changes to the core
  protocol

Please accept my apologies for however I deviated from that goal.

I am trying to get us to a place where we can have productive discussions
and improve the quality of our protocols.  Right now I don't think we're
having very productive discussions; in fact, we're holding up progress on a
document that looks likely to become widely deployed by asking it to do
more than is reasonable for it to do.

> Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the 
> following title:"IETF Guidelines for Conduct". In particular:
> 
>     " Regardless of these individual differences, participants treat
>     their colleagues with respect as persons especially
>         when it is difficult to agree with them: treat other
>     participants as you would like to be treated ".
> 
> I wrote:
> 
> (...)
> 
>      I will go one step further: if the client wants to inspect the 
> token and
>      if the format of the token is unknown to the client, then the client
> will simply stop its further transmission. For some clients, preserving 
> their
> privacy may be more important than performing an access to a RS.
> 
> You responded :
> 
>     That may be true, but I agree with Vittorio that this document needs to
>     strongly discourage clients from doing so, since they would 
> be**_breaking _*
> *_a __protocol invariant_ if they do.
> 
> If "this may be true", then you should consider that the token 
> inspection by a client may be useful and thus should not be prevented.

I do in fact agree that token inspection by a client can be useful in at
least some situations.  However, RFC 6749 is quite clear that "the [access
token] is usually opaque to the client".  A requirement that the access
token MUST be inspectable by the client is incompatible with something that
"is usually opaque to the client".

> However, there is no guarantee that it may always be performed.

I agree that this is the current state of affairs.

> You are using the wording" _breaking a protocol invariant_". In which 
> RFC (related to OAuth) has such a "protocol invariance" been first 
> mandated ?

RFC 6749, per above.

> I attempted to find an RFC using the wording "protocol invariant". I 
> found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1
> with the topic " Declaring Protocol Invariants", using the following terms:
> 
> Declaring a protocol's invariants represents a promise made by the 
> protocol's developers that certain bits in the wire image, and behaviors
>     observable in the wire image, will be preserved through the 
> specification of all future versions of the protocol.

Perhaps my usage of the term "protocol invariant" was confusing or
inappropriate.  I meant to say that you are trying to change a property of
the core protocol specification; whether or not it is best described as an
"invariant" is immaterial to my point.  In other words, a generic OAuth 2.0
client has to be prepared to deal with access tokens that are opaque to it.

> Using these explanations, I have difficulties to understand how 
> preventing the content of a JWT to be inspected by a client may be 
> considered
> as "a promise made by the protocol's developers that certain bits in the 
> wire, and behaviors observable in the wire, will be preserved
> through the specification of all future versions of the protocol".
> 
> I probably missed something. Would you be able to explain ?

(I tried to above.)

> A second point:
> 
> As a co-author of RFC 3161 published in August 2001 and of RFC 36268 
> published in November 2003 to name a few of the RFCs
> to which I contributed, I am not aware of any reference to an ISO 
> document made into a RFC. This seems to be a common practice.
> When I used the term "refer", I was not asking to place a reference to 
> an ISO document in this working draft but to allow everybody in
> the WG to have the ability to have a look at its content (and for free). 

Ah, I misunderstood you then; sorry about that.
Using readily-available documents where someone has already written down
relevant information is a great way to quick-start a discussion, but I
thought you wanted us to have this I-D accept wholesale the definitions
from the ISO document without further discussion.

> Table 3 is simply a quick "reference" to ten privacy principles.
> 
> A third point:
> 
> RFC 6973 (Privacy Considerations for Internet Protocols) has been 
> published in July 2013. Its introduction mentions:
> 
> The guidance provided here can and should be used to _assess the privacy 
> considerations of protocol_, architectural,
>      and operational _specifications_ (...)
> 
>     The guidance provided here is meant to help the thought process of 
> privacy analysis; it does not provide specific directions
>      for how to write a privacy considerations section.
> 
> Section 7 (Guidelines) mentions :
> 
>     This section provides guidance for document authors in the form of a 
> questionnaire about a protocol being designed.
>     The questionnaire may be useful at any point in the design process, 
> particularly after document authors have developed
>     a high-level protocol model as described in [RFC4101].
> (...)
> However, by carefully considering the answers to each question, document 
> authors should be able to produce a comprehensive
>     analysis that can serve as the basis for discussion of whether the 
> protocol adequately protects against privacy threats.

I actually think it would be quite valuable to perform this kind of
analysis for RFC 6749 (and extensions).  Its usage has evolved quite a lot
from its initial origins, and there are (as you have pointed out) many
areas that are lacking.  Would you be willing to start an I-D on this
topic?  I think that it would be more valuable to do something systematic
than to try to do something piecemeal for this document just because it is
a document the WG is currently working on.

> An important item which is addressed both in ISO 29100 and RFC 6973 in 
> section 7.1 is "Data Minimization". RFC 6973 mentions:
> 
> a.*Identifiers*.What identifiers does the protocol use for 
> distinguishing initiators of communications?
> Does the protocol use identifiers that allow different protocol 
> interactions to be correlated?
> What identifiers could be omitted or be made less identifying while 
> still fulfilling the protocol’s goals?
> 
> b.*Data*.What information does the protocol expose about individuals, 
> their devices, and/or their device usage (other than the identifiers 
> discussed in (a))?
>       To what extent is this information linked to the identities of the 
> individuals?How does the protocol combine personal data with the 
> identifiers discussed in (a)?
> 
> c.*Observers*.Which information discussed in (a) and (b) is exposed to 
> each other protocol entity (i.e., recipients, intermediaries, and enablers)?
> Are there ways for protocol implementers to choose to limit the 
> information shared with each entity?  µ
> Are there operational controls available to limit the information shared 
> with each entity?
> (...)
> 
> e.*Persistence of identifiers*.What assumptions are made in the protocol 
> design about the lifetime of the identifiers discussed in (a)?
>       Does the protocol allow implementers or users to delete or replace 
> identifiers?
> 
> f.*Correlation*.Does the protocol allow for correlation of 
> identifiers?Are there expected ways that information exposed by the 
> protocol will be combined
>      or correlated with information obtained outside the protocol?
> 
> RFC 6973 also mentions in section 7.2 (User Participation) (while ISO 
> 29100 uses the wording "Consent and choice"):
> 
> a.*User control*.What controls or consent mechanisms does the protocol 
> define or require before personal data or identifiers are shared or 
> exposed via the protocol?
> 
> 
> All the above questions are useful to assess privacy considerations 
> about the protocol. Some key questions related to OAuth are the following:
> 
>   * considering the current semantics of the "sub" claim, what are the
>     implications in terms of "correlation" ?
>   * considering the current semantics of the scope request parameter (or
>     of any other token request parameter), what are the implications in
>     terms of "user control" ?

I agree: these are "key questions related to OAuth".  Where I perhaps
disagree with you is that I believe they are key questions relating to the
protocol as a whole; the discussion so far seems to indicate that you wish
to both perform this analysis and change the protocol all as part of the
JWT profile document.  I think the tasks are better performed separately.

> The next version of this document should use RFC 6973 more closely as a 
> guidance to "_assess the privacy considerations __of the protocol_ and 
> of operational _specifications_".

I fully support having privacy considerations sections that discuss the
privacy properties of the protocol in question, even including aspects that
are currently lacking.

However, I do not believe that a JWT profile for OAuth use is the place to
make changes to the core OAuth protocol that improve its privacy properties.
(If we can specify the token format in a way has better privacy properties
than alternative token formats, we should, of course, but we can't change
the protocol itself.)
Making changes to OAuth that improves its privacy properties is a laudable
goal, and I would happily read any I-Ds that proposed such protocol changes
(though I fear that the current deployment/semantics may constrain the
degree to which OAuth 2.0 can be improved and have much more hope for the
txauth group to produce a protocol with good privacy properties).  The
discussion so far has not convinced me that this document is the right
document in which to do so.

Thanks,

Ben

> 
> > Hi Denis,
> >
> > You seem to be continuing to be operating under incorrect assuptions about
> > how OAuth 2.0 works, and have proceeded to make long chains of reasoning
> > that, unfortunately, are not based on a solid foundation.  In order to
> > reduce the amount of frustration amongst all participants, in the future I
> > strongly suggest that you make sure you have the fundamentals correct
> > before going into long chains of reasoning.
> >
> > Furthermore, while you have indeed identified some areas where the current
> > OAuth ecosystem could be improved, I reiterate that the current document,
> > defining a token format that is optional to use, is not the place to make
> > changes to how OAuth works.  I think you do everyone a disservice for
> > attempting to suggest that this document should do so.
> >
> > Because there is so much based on a flawed foundation, I will not respond
> > inline to every point, but do see a few things where further clarification
> > would be useful.
> >
> > On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
> >> Hello Vittorio,
> >>
> >> Your reply was amazingly fast. Responses are between the lines.
> >>
> >>> Thanks Denis for the thorough commentary.
> >>>
> >>> /> The title of this spec./
> >>>
> >>> Fixed, thanks!
> >>>
> >>> /> The client MUST NOT inspect the content of the access token/
> >>>
> >>>
> >>> This is really a sticky point. I really want to acknowledge your PoV
> >>> on this, but at the same time I found this to be one of the biggest
> >>> sources of issues
> >>> in the use of JWT for access tokens hence I feel we really need to
> >>> give solid guidance here. Let me expand further on the reasoning
> >>> behind it,
> >>> and perhaps we can get to language that satisfies both PoVs.
> >>>
> >>>
> >>> To me the key point is that clients should not write /code/ that
> >>> inspects access tokens. Taking a dependency on the ability to do so is
> >>> ignoring fundamental information
> >>> about the architecture and relationships between OAuth roles, and
> >>> suggests an ability of the client to understand the semantic of the
> >>> content that cannot be assumed
> >>> in the general case. I expanded on the details in my former reply to
> >>> you on this topic, I would recommend referring to it.
> >>>
> >>> Clients violating this simple principle has been one of the most
> >>> common sources of production issues I had to deal with in the past few
> >>> years, and one of the hardest
> >>> to remediate given that clients are hard to update and sometimes the
> >>> things they relied on were irremediably lost. This is why I am
> >>> inclined to put in here strong language.
> >>>
> >>> That said: I have nothing against client developers examining a
> >>> network trace and drawing conclusions based on the content of what
> >>> they see. That doesn’t create any hard
> >>> dependencies and has no implications in respect to changes in the
> >>> solution behavior. However I am not sure how to phrase that in the
> >>> specification, given that referring
> >>> to the client inevitably refers to its code. I am open to suggestions.
> >>>
> >> First of all, a "*MUST NOT* "should not be placed in a privacy
> >> considerations section, but in the main body of the document.
> >> The goal of a privacy considerations section is to provide explanations,
> >> but not to introduce additional requirements.
> > That's not actually a requirement.  In many cases it makes sense to avoid
> > putting normative requirements in the security and/or privacy
> > considerations sections, but it is very much a thing that is done in many
> > RFCs, and in some cases it is useful to do so.
> >
> >> Then after, since this section is about privacy considerations, it is
> >> important to refer to an ISO standard that has been published 9 years ago.
> > Is it?  I don't see much precedent for IETF documents referencing this ISO
> > standard.  If it's so important you'd think that we'd have been citing it
> > with regularity.  Since this will be the first or second time, I think you
> > need to provide some additional justification as to how the topics it
> > covers fit within the existing IETF BCPs for how we treat security and
> > privacy considerations before we conclude that it is the appropriate
> > reference.
> >
> >> It is ISO 29100 (Information technology — Security techniques — Privacy
> >> framework). Most of the ISO standards need to be bought.
> >> However, there are a few exceptions and this standard can be freely
> >> downloaded from the ISO web site, if you accept some conditions,
> >> using this URL:
> >>
> >>      https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
> >>
> >> ISO 29100, even if it is outdated on some aspects (it only deals with
> >> two entities), identifies ten principles (See Table 3).
> >>
> >>      1. Consent and choice
> >>
> >>      2. Purpose legitimacy and specification
> >>
> >>      3. Collection limitation
> >>
> >>      4. Data minimization
> >>
> >>      5. Use, retention and disclosure limitation
> >>
> >>      6. Accuracy and quality
> >>
> >>      7. Openness, transparency and notice
> >>
> >>      8. Individual participation and access
> >>
> >>      9. Accountability
> >>
> >>      10. Information security
> >>
> >>      11. Privacy compliance
> >>
> >> If the client is unable to inspect the token, then openness and
> >> transparency do not exist any more.
> >>
> >> Since there is no formal protocol in OAuth 2.0  for "consent and
> >> choice", the only way for a client for denying its consent is to inspect
> >> the token
> >> and to stop its transmission if the content of the token is not
> >> considered to be adequate for it.
> >>
> >> Since you are open to suggestions, would you please reconsider the text
> >> I proposed: it simply states that if the client wants to inspect the token,
> >> it will not necessarily be in a position to do it. It is simply a
> >> warning, but this warning does not prevent the client to attempt to
> >> inspect the token .
> >>
> >> I will go one step further: if the client wants to inspect the token and
> >> if the format of the token is unknown to the client, then the client
> >> will simply
> >> stop its further transmission. For some clients, preserving their
> >> privacy may be more important than performing an access to a RS.
> > That may be true, but I agree with Vittorio that this document needs to
> > strongly discourage clients from doing so, since they would be breaking a
> > protocol invariant if they do.
> >
> > Thanks,
> >
> > Ben
> >
> >>>>   3)…
> >>> I have a pretty hard time following the chain of reasoning in this
> >>> section. Let me attempt to tackle it to the best of my understanding.
> >>>
> >>> I think the key might be
> >>>
> >>> /> a client should be able to choose whether it wishes the sub claim
> >>> to contain [..]
> >>>
> >>> /
> >>>
> >>> I don’t think that should be a choice left to the client. In business
> >>> systems, my experience is that the type of identifiers to be used
> >>> (when the IdP gives any choice at all)
> >>>   is established at resource provisioning time. I am not aware of
> >>> mechanisms thru which a client signals the nature of the identifier to
> >>> be used, nor that would be fully
> >>> feasible (the resource knows what it needs to perform its function).
> >>>
> >> Consent and choice is the first of the ten privacy principles. Since
> >> OAuth has not been constructed taking into considerations this privacy
> >> principle,
> >> it is quite "normal" that you don't observe protocols able to do it at
> >> the present time.
> >>
> >>> Furthermore:
> >>>
> >>> /> which has nothing to do with uniqueness since the value changes for
> >>> every generated token.
> >>>
> >>> /
> >>>
> >>> Again, this is something that was touched on in my former reply to
> >>> your message. As long as an identifier identifies one resource only,
> >>> it satisfies uniqueness. It doesn’t have to be a singleton.
> >>>
> >> It is a matter of interpretation. I stick to the definition given in RFC
> >> 7519 (section 4.1.2):
> >>
> >> *T**he subject value MUST either be scoped to be locally unique in the
> >> context of the issuer or be globally unique.*
> >>
> >> However, the "context of the issuer" is left undefined.
> >>
> >>> Finally, the scope is optional (for good reasons: 1^st party and non
> >>> delegation scenarios don’t require it) hence it cannot be relied upon
> >>> for properties that should hold in every scenario.
> >>>
> >> I would not say that the scope request parameter is a nice way to choose
> >> which attributes should be placed in a JWT. However, considering the
> >> limitations placed
> >> in this document, it is the ONLY way to do. In my email sent before the
> >> virtual meeting, I wrote: "Allowing a client to only specify a scope and
> >> a resource is very restrictive".
> >>
> >> Clause 2.2.2 (second paragraph) states:
> >>
> >> ***This profile does not introduce any mechanism for a client to**
> >> ******directly request the presence of specific claims in JWT access**
> >> ******tokens*, as the authorization server can determine what additional
> >> claims are required by a particular resource server by taking in
> >> consideration the client_id of the client, the scope and the resource
> >> parameters included in the request.
> >>
> >> Currently, the client has no control of the claims that will be placed
> >> in a JWT and further more the current wording of privacy consideration
> >> section
> >> prevents the client to have any inspection of the attributes that have
> >> been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not
> >> fulfilled.
> >>
> >> There are more implications. If, in the future, a mechanism is defined
> >> to allow the client to choose the type of the attributes that should be
> >> placed in a JWT,
> >> then the "sub" claim is insufficient. Taking into consideration my
> >> previous email, four types of attributes types would need to be specified:
> >>
> >> The client should be able to choose whether it wishes a claim that contains:
> >>
> >>    *      a global unique identifier for all ASs ("globally unique"),
> >>    *      a unique identifier for each AS ("locally unique in the context
> >>      of the issuer"),
> >>    *      a different pseudonym for each RS, or
> >>    *      a different pseudonym for each authorization token request.
> >>
> >> Clause 2.2.2 states:
> >>
> >> *   the authorization server can determine what additional**
> >> ******claims are required by a particular resource server* by taking in
> >> consideration the client_id of the client, the scope and the resource
> >> parameters included in the request.
> >>
> >> I don't believe this is true in general. Considering its privacy
> >> preferences, only the client may know what is appropriate: not the AS,
> >> neither the RS.
> >>
> >>> In summary: per the preceding thread on this topic, the consensus was
> >>> that varying the sub content was a satisfactory way of protecting
> >>> against correlation.
> >>>
> >> "/if all you have is a hammer, everything looks like a nail/".
> >>
> >> When the only parameter that can be used is the "sub" claim, then the
> >> only solution is to place everything into it.
> >>
> >>> I don’t a gree that clients should have a mechanism to request
> >>> different sub flavors, as that decision should be done out of band by
> >>> the AS and RS; and the scope isn’t always available anyway.
> >>>
> >> While it would be nice to have such a mechanism, we are not going to
> >> define such a mechanism during a second WGLC.
> >>
> >> The privacy considerations section should only inform the readers about
> >> the limitations of the protocol in terms of privacy.
> >> I have proposed text to address the point. If you would prefer a
> >> different wording to address this point, please make another proposal.
> >>
> >>> /> targeting of access tokens/
> >>>
> >>> Let me think about that a bit longer.
> >>>
> >>> I acknowledge that the decision of including an audience has the
> >>> effect of letting the AS track when the client accesses a particular
> >>> resource,
> >>> but at the same time that’s completely mainstream and very much by
> >>> design in a very large number of cases. As such, I find the language
> >>> you are suggesting to be potentially confusing, as it positions this
> >>> as an exception vs a privacy protecting mainstream that is in fact not
> >>> common,
> >>> and ascribes to the client more latitude than I believe is legitimate
> >>> to expect or grant.
> >>>
> >>> I’ll try to come up with concise language that clarifies to the reader
> >>> that the current mechanism does allow AS tracking.
> >>>
> >> Please do so.
> >>
> >> Denis
> >>
> >>> *From: *OAuth  on behalf of Denis
> >>> 
> >>> *Date: *Wednesday, April 29, 2020 at 09:12
> >>> *To: *"oauth@ietf.org" 
> >>> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> >>> for OAuth 2.0 Access Tokens"
> >>>
> >>> You will find four comments numbered 1) to 4).
> >>>
> >>> *1) *The title of this spec. is:
> >>>
> >>> JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
> >>>
> >>> So, this spec. is supposed to be targeted to OAuth *2.0. * However,
> >>> the header at the top of the page omits to mention it.
> >>>
> >>> Currently, it is :
> >>>
> >>> Internet-Draft OAuth Access Token JWT Profile           April 2020
> >>>
> >>> It should rather be:
> >>>
> >>> Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020
> >>>
> >>> *2)* The following text is within section 6.
> >>>
> >>> The client MUST NOT inspect the content of
> >>> the access token: the authorization server and the resource server
> >>> might decide to change token format at any time (for example by
> >>> switching from this profile to opaque tokens) hence any logic in the
> >>> client relying on the ability to read the access token content would
> >>> break without recourse.
> >>> Nonetheless, authorization servers should
> >>> not assume that clients will comply with the above.
> >>>
> >>> It is of a primary importance that clients MAY be able to inspect
> >>> tokens before transmitting them.
> >>> The "MUST NOT" is not acceptable.
> >>>
> >>> The above text should be replaced with:
> >>>
> >>> Reading the access token content may be useful for the user to verify
> >>> that
> >>> the access token content matches with its expectations. However,
> >>> the authorization server and the resource server might decide to
> >>> change the
> >>> token format at any time.  Thus, the client should not expect to
> >>> always be
> >>> in a position to read the access token content.
> >>>
> >>> The remaining of the text about this topic is fine.
> >>>
> >>>
> >>> *3) *The next topic is about the sub claim.
> >>>
> >>> The text states:
> >>>
> >>> Although the ability to correlate requests might be required by
> >>> design in many scenarios, there are scenarios where the authorization
> >>> server might want to prevent correlation to preserve the desired
> >>> level of privacy. Authorization servers should choose how to assign
> >>> sub values according to the level of privacy required by each
> >>> situation.
> >>>
> >>> I have a set of questions:
> >>>
> >>>   1. How can authorization servers choose how to assign sub values
> >>>      according to the level of privacy required "by each situation" ?
> >>>   2. How can authorization servers know the level of privacy required
> >>>      "by each situation" ?
> >>>   3. How can the users be informed of the level of privacy required "by
> >>>      each situation" ?
> >>>   4. How can the users *consent* with the level of privacy required "by
> >>>      each situation" ?
> >>>
> >>> Currently, the request MUST include either a resource parameter or an
> >>> aud claim parameter, while it MAY include a scope parameter.
> >>>
> >>> The syntax of the scope parameter is a list of space-delimited,
> >>> case-sensitive strings (RFC 6749). It is thus subject to private
> >>> agreements
> >>> between clients and Authorization Servers. Since the scope is being
> >>> returned, it is a primary importance that the returned scope matches
> >>> with its expectations before transmitting the token to a Resource Server.
> >>>
> >>> In theory, a client should be able to choose whether it wishes the sub
> >>> claim to contain :
> >>>
> >>>    * a global unique identifier for all ASs ("globally unique"),
> >>>    * a unique identifier for each AS ("locally unique in the context of
> >>>      the issuer"),
> >>>    * a different pseudonym for each RS, or
> >>>    * a different pseudonym for each authorization token request.
> >>>
> >>> The only variable parameter that it can use for this purpose in the
> >>> token request is the scope parameter.
> >>>
> >>> RFC 7519 states is section 4.1.2:
> >>>
> >>> The subject value MUST either be scoped to be locally unique in the
> >>> context of the issuer
> >>> or be globally unique.
> >>>
> >>> It is quite hard to recognize that the sub claim is able to carry a
> >>> different pseudonym for each RS, i.e. for case (c), or
> >>> a different pseudonym for each authorization token request, i.e. for
> >>> case (d), which has nothing to do with uniqueness
> >>> since the value changes for every generated token.
> >>>
> >>> This has implications about the following text:
> >>>
> >>> For instance: if a solution requires preventing tracking
> >>> principal activities across multiple resource servers, the
> >>> authorization server should ensure that JWT access tokens meant for
> >>> different resource servers have distinct sub values that cannot be
> >>> correlated in the event of resource servers collusion.
> >>>
> >>> Since it addresses case (c).
> >>>
> >>> and also about the following text:
> >>>
> >>> 4.b) Similarly: if a solution requires preventing a resource server from
> >>> correlating the principal’s activity within the resource itself, the
> >>> authorization server should assign different sub values for every JWT
> >>> access token issued.
> >>>
> >>> Since it addresses case (d).
> >>>
> >>> This means that the current text placed in the privacy considerations
> >>> section was a good attempt to address the case,
> >>> but that the text needs to be revised.
> >>>
> >>> Proposed text replacement for all the previously quoted sentences:
> >>>
> >>> According to RFC 7519 (4.1.2): The subject value MUST either be scoped
> >>> to be locally unique in the context of the issuer or be globally unique.
> >>>
> >>> When the sub claim contains a globally unique identifier, this allows
> >>> to correlate principal activities across multiple resource servers,
> >>> while in addition,
> >>> this globally unique identifier may also allow to correlate the
> >>> principal activities on servers where no access has been performed by
> >>> the principals
> >>> to these servers but where the same globally unique identifiers are
> >>> being used by these servers.
> >>>
> >>> When the sub claim contains a locally unique identifier in the context
> >>> of the issuer, this also allows the tracking of principal activities
> >>> across multiple resource servers.
> >>>
> >>> The scope request parameter is the only way to influence on the
> >>> content of the sub claim parameter. Its meaning is subject to a
> >>> private agreement
> >>> between the client and the AS, which means that the use of the scope
> >>> parameter is the only way to choose between a locally unique identifier
> >>> in the context of the issuer or a globally unique identifier.
> >>>
> >>> Since the scope parameter is being returned, it is a primary
> >>> importance that the returned scope matches with the expectations of
> >>> the client before transmitting
> >>> the token to a Resource Server.
> >>>
> >>> However, there are other cases where the client would like to be able
> >>> to choose whether it wishes the sub claim to contain :
> >>>      - a different pseudonym for each RS so that different resource
> >>> servers will be unable to correlate its activities, or
> >>>      - a different pseudonym for each authorization token request, so
> >>> that the same resource server cannot correlate its activities
> >>> performed at different instant of time.
> >>>
> >>> Considering the semantics of the sub claim, these two cases cannot be
> >>> currently supported.
> >>>
> >>>
> >>> *4) *The next topic is about the targeting of access tokens
> >>>
> >>> Text had been proposed before the last conference call. Then, the
> >>> topic has been presented at the very end of the last conference call,
> >>> but no text has been included
> >>> in the next draft.
> >>>
> >>> Here is a revised text be included in the privacy considerations section:
> >>>
> >>> For security reasons, some clients may be willing to target their
> >>> access tokens but, for privacy reasons, may be unwilling to disclose
> >>> to Authorization Servers
> >>> an identification of the Resource Servers they are going to access, so
> >>> that Authorization Servers will be unable to know which resources
> >>> servers are being accessed.
> >>> The disclosure of the Resource Servers names allows the Authorization
> >>> Servers to list all the Resource Servers being access by all its users
> >>> and in addition to list pairs
> >>> of (Principal, Resource Servers) which allow to trace all the users
> >>> accesses to Resource Servers performed through a given Authorization
> >>> Server. When a token is targeted,
> >>> this profile does not contain provisions to address these two threats.
> >>>
> >>> Denis
> >>>
> >>>      Hi all,
> >>>
> >>>      This is a second working group last call for "JSON Web Token (JWT)
> >>>      Profile for OAuth 2.0 Access Tokens".
> >>>
> >>>      Here is the document:
> >>>
> >>>      https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
> >>>
> >>>      Please send your comments to the OAuth mailing list by April 29, 2020.
> >>>
> >>>      Regards,
> >>>
> >>>       Rifaat & 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
> 
> 


From nobody Fri May  8 20:21:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487F43A086E for ; Fri,  8 May 2020 20:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAlIfbRC_FTu for ; Fri,  8 May 2020 20:21:18 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E983A086D for ; Fri,  8 May 2020 20:21:17 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id y24so3033865edo.0 for ; Fri, 08 May 2020 20:21:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fd3Pj3tMOVCy/+6Pq+H2XRCSjst4KJd/iKSzlA6ksK0=; b=DP2zOghRlgcqxQywtXc82PQBuqqh9ar2WniItuGC3c4Lb9RQOr2cH+vl9ZpYjW2RQC s4fjBj4/CvfMOmDcOPURJM5tgPcrupWpFeTmNWGrDJTa/3Gf8CwB7LHoRANDcz1sCFKZ jEvdGuxa1TRtYmqqzjcaw0Ka7F199rCZKWaF1pHEgwwcMRhihkYRKNHFCn45d9Yv3m6I 6hUigGcJhneF0kk0wp65hen3GFO0zuliFtfjcNNzYA+JfgP36+NjYHDlz6JFXzP02w62 bBvJIAU8a8amxSCdimU+tMnYXxSEv1JVX5ZsinI5alHdsQohmgly0jYVJIUrSYuovx0+ TXxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fd3Pj3tMOVCy/+6Pq+H2XRCSjst4KJd/iKSzlA6ksK0=; b=IwSJEnRJsPbO9AgUc3nYMdFVHlkGIohzh+HMi/hzmbGk3+zJppPtdC9fNDoT8kIRA5 EAXNCVaG5l3JcI6OYRGeo93rDiQB+LgfZ0cHkb+C/bbdpDtyDe+nXnx9cQxQyYAyPE8v D1YacAYktP6uPNRpNgMMHjYQwoQCL/G83Tt3h4h9CB778x7BFd8YNPuKCFzldgPovtyE wxYo1io9XEfV4Pnzp6PjlcGbF+hu3CtE8n3SuxJ78O1NZtSuYbYGmsZrurED/rfrg7ZT sesqWXzQI0LpnkbPDbwQWnsH0jayyyT0xa6YIyZafwFiRExidxpucEgta3iuTTeovAhh q2Hw==
X-Gm-Message-State: AGi0PuYLk8LKNKipPfKhp9IDvqTrSaaQhiZ6YNM24pgmt48Mym80BXvn LwkZhVrQoD5Bk/i31OaXGACE1XcRHiX2eTfmYith6Iw5HBc=
X-Google-Smtp-Source: APiQypIsiOPFxCJdd1QhsdPS8QaVx/Ctvor/RRhei+TQUaqfZsTpMhA29uDjH7ZEoUXeRiNCNPoWRd7wF7cE5waOVhA=
X-Received: by 2002:a50:8b06:: with SMTP id l6mr4711137edl.190.1588994475627;  Fri, 08 May 2020 20:21:15 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Jared Jennings 
Date: Fri, 8 May 2020 22:21:04 -0500
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000045243305a52e9b1c"
Archived-At: 
Subject: Re: [OAUTH-WG] May 11th Interim Meeting Materials
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 May 2020 03:21:22 -0000

--00000000000045243305a52e9b1c
Content-Type: text/plain; charset="UTF-8"

I will be taking notes using the following link.
https://docs.google.com/document/d/1tPxkaOf74szvDLSEpzXV8lMgSEwcHYMC73OUOv3BKxQ/edit?usp=sharing

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Fri, May 8, 2020 at 5:25 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> You can find the meeting material for the May 11th meeting at the
> following link:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-08/session/oauth
>
> Regards,
>  Rifaat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000045243305a52e9b1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I will be taking notes using the following link.

-Jared
Skype:jare=
dljennings
Signal:+1 816.730.9540
WhatsApp:=C2=A0+1 816=
.678.4152


On Fri, May 8, 2020 at 5:2=
5 PM Rifaat Shekh-Yusef <rifaat=
.ietf@gmail.com> wrote:
All,

Yo=
u can find the meeting material for the May 11th meeting at the following=
=C2=A0link:

Regards,
=C2=A0Rifaat


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000045243305a52e9b1c--


From nobody Fri May  8 20:34:40 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606DC3A0883 for ; Fri,  8 May 2020 20:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57Gt6V-N7PN0 for ; Fri,  8 May 2020 20:34:34 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73013A0882 for ; Fri,  8 May 2020 20:34:34 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id y26so3883838ioj.2 for ; Fri, 08 May 2020 20:34:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JKx/TibfJLf/8hf3TadJ9NgntbchDpuFEsXzmL+PelU=; b=1Aw4MClI1AEuO6DkBNOJ8+trd3QSJJijRPbse27a0ef2Zx2Sz4/6BE6EOnMZefjw9r ZeKbtJhm7IX/NIdyQV8+zsmuG/zzaLM2aKoqeARqEOseTyHtcjT8uF/YFwlyASRF1muK 8SWTLFOJLcAJVuK9LLk676tkxWQyelSN9m5HhXQf9kCetbhAgaZiFSD8Z2xi0W60MEe4 wq9eaJ5ULvEKG/CGRMS1wP+TiVzoAmQ2QRbZKCJKKdBK7+E7Vbk70HCiGff2LJ4FwMQW mSyjfZ8hI7j0eHOv9Vl08QYhFSNr7BJGf7uK8w53rkYMzNDKYpb7a6Aa9yzWJRlDXDem I31w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JKx/TibfJLf/8hf3TadJ9NgntbchDpuFEsXzmL+PelU=; b=d/RnsXPqoCkLG8Devh0fkcrdQOiVEp8jiAy7nCeUZnPj6PiD9bMo2ZNl/pGkpu3QIX RwYUblyRJy2t7JTZ3PHWS5cCaoqJA1plV9538oPE76vde4/UMcWueCaMs2TqhYj65eV8 lMmp4zNzA+dLXKycu+ZzXKbr+icskq820Oy1OAqewvRksq/4MnuEQwjkuLg7cUbawwp3 pH0g14by1N1jGmwEzmiHh05chSMyDcena2a+nqvEequTm1MXdsisejU9sKlTS9AN8Rlj TqRt9GJTK8KRot9hDFUk/5s4NzoTQtnMqSusWlSBGDmD7Jn8Ay9rwGqYaCgiExBS2fyV m79A==
X-Gm-Message-State: AGi0PuZLCDC9xpTjTQePgBabbPmM42rTOSm7lJCdIG96jKsEvX+GOaSy qleN2y/Z8iJM0ZuMihgCfs4A+EEx1Ak=
X-Google-Smtp-Source: APiQypKl/3Ckzkd7IExEqGQtFdkN91gB2IEobKK9IkgqGeYEq9kdcjc+NBHVLiUkI3dSB/4wSBniYw==
X-Received: by 2002:a05:6638:614:: with SMTP id g20mr5792006jar.85.1588995272605;  Fri, 08 May 2020 20:34:32 -0700 (PDT)
Received: from mail-il1-f174.google.com (mail-il1-f174.google.com. [209.85.166.174]) by smtp.gmail.com with ESMTPSA id y15sm1687583ilg.21.2020.05.08.20.34.31 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 20:34:31 -0700 (PDT)
Received: by mail-il1-f174.google.com with SMTP id n11so3336070ilj.4 for ; Fri, 08 May 2020 20:34:31 -0700 (PDT)
X-Received: by 2002:a92:ddca:: with SMTP id d10mr6435852ilr.166.1588995271227;  Fri, 08 May 2020 20:34:31 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Fri, 8 May 2020 20:34:20 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000b1030805a52eca02"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 May 2020 03:34:39 -0000

--000000000000b1030805a52eca02
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  You=
=E2=80=99re
> concerned about =E2=80=9Cthe amount of explanation this will take=E2=80=
=9D.  That=E2=80=99s
> optimizing for spec simplicity =E2=80=93 a goal that I do understand.  Ho=
wever, by
> writing these few sentences or paragraphs, we=E2=80=99ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won=
=E2=80=99t
> have to change their deployments.  That=E2=80=99s optimizing for interope=
rability
> and minimizing the burden on developers, which are far more important.


I appreciate the concern about optimizing for spec simplicity. I also agree
that spec simplicity should not necessarily be the driving goal.

However, what you've described is the opposite of interoperability and
minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without
any exceptions, will optimize for interoperability between OAuth 2.1
clients and servers. Without the requirement of PKCE, there will always be
the question of "but does this OAuth 2.1 client work with this OAuth 2.1
server or not?", which will only be able to be answered by investigating
the docs to look for PKCE support, or by checking the AS metadata document
if it publishes one (which it is not required to do).

Optimizing for interoperability and minimizing the burden on developers is
absolutely a good goal, and requiring PKCE is a great way to accomplish
that. OAuth 2.0 and OpenID Connect implementations that don't support PKCE
will continue to work as they currently do, they just won't be able to call
themselves OAuth 2.1 compliant, just as is the case as if they don't follow
the other recommendations that are in OAuth 2.1 and the Security BCP.

Aaron


On Thu, May 7, 2020 at 6:42 PM Mike Jones 
wrote:

> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  You=
=E2=80=99re
> concerned about =E2=80=9Cthe amount of explanation this will take=E2=80=
=9D.  That=E2=80=99s
> optimizing for spec simplicity =E2=80=93 a goal that I do understand.  Ho=
wever, by
> writing these few sentences or paragraphs, we=E2=80=99ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won=
=E2=80=99t
> have to change their deployments.  That=E2=80=99s optimizing for interope=
rability
> and minimizing the burden on developers, which are far more important.
>
>
>
> As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have very d=
ifferent
> ramifications on interoperability=E2=80=9D.
>
>
>
> Even if you=E2=80=99re optimizing for writing, taking a minimally invasiv=
e
> protocol change approach will optimize that, overall.  If we proceed as
> you=E2=80=99re suggesting, a huge amount of writing will occur on StackOv=
erflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask =E2=80=9CWhy do I have to change my deployed code?=E2=
=80=9D with the
> answers being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99s no=
 need to change
> your deployed code.=E2=80=9D
>
>
>
> I=E2=80=99d gladly write a few sentences in our new specs now to prevent =
ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you=E2=80=99re ready to incorporate them into the spec text.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt 
> *Cc:* OAuth WG ; Torsten Lodderstedt <
> torsten@lodderstedt.net>; Mike Jones 
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
>
>
> Backing up a step or two, there's another point here that I think has bee=
n
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE a=
s
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP fo=
r
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
>

--000000000000b1030805a52eca02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Aaron, I=
 believe you=E2=80=99re trying to optimize the wrong thing.=C2=A0 You=E2=80=
=99re concerned about =E2=80=9Cthe amount of explanation this will take=E2=
=80=9D.=C2=A0 That=E2=80=99s optimizing for spec simplicity =E2=80=93 a goa=
l that I do understand.=C2=A0 However, by writing these few sentences or pa=
ragraphs, we=E2=80=99ll make it clear to developers that hundreds or thousa=
nds of deployed OpenID Connect RPs won=E2=80=99t have to change their deplo=
yments.=C2=A0 That=E2=80=99s optimizing for interoperability and minimizing=
 the burden on developers, which are far more important.
<=
br>
I appreciate the concern about optimizing for spec simplicity=
. I also agree that spec simplicity should not necessarily be the driving g=
oal.

However, what you've described is the opp=
osite of interoperability and minimizing the burden on developers. Requirin=
g PKCE in OAuth 2.1, without any exceptions, will optimize for interoperabi=
lity between OAuth 2.1 clients and servers. Without the requirement of PKCE=
, there will always be the question of "but does this OAuth 2.1 client=
 work with this OAuth 2.1 server or not?", which will only be able to =
be answered by investigating the docs to look for PKCE support, or by check=
ing the AS metadata document if it publishes one (which it is not required =
to do).

Optimizing for interoperability and minimi=
zing the burden on developers is absolutely a good goal, and requiring PKCE=
 is a great way to accomplish that. OAuth 2.0 and OpenID Connect implementa=
tions that don't support PKCE will continue to work as they currently d=
o, they just won't be able to call themselves OAuth 2.1 compliant, just=
 as is the case as if they don't follow the other recommendations that =
are in OAuth 2.1 and the Security BCP.

Aaron=C2=A0=

=C2=A0

On Thu, May 7, 2020 at 6:42 PM Mike Jones <Michael.Jones@mi=
crosoft.com> wrote:











Aaron, I believe =
you=E2=80=99re trying to optimize the wrong thing.=C2=A0 You=E2=80=99re con=
cerned about =E2=80=9Cthe amount of explanation this will take=E2=80=9D.=C2=A0 That=E2=80=99s optimizing for=
 spec simplicity =E2=80=93 a goal
 that I do understand.=C2=A0 However, by writing these few sentences or par=
agraphs, we=E2=80=99ll make it clear to developers that hundreds or thousan=
ds of deployed OpenID Connect RPs won=E2=80=99t have to change their deploy=
ments.=C2=A0 That=E2=80=99s optimizing for interoperability and minimizing
 the burden on developers, which are far more important.


=C2=A0<=
/u>


As Brian Campbell=
 wrote, =E2=80=9CThey are not equivalent and have very different ram=
ifications on interoperability=E2=80=9D.=



=C2=A0<=
/u>


Even if you=E2=80=
=99re optimizing for writing, taking a minimally invasive protocol change a=
pproach will optimize that, overall.=C2=A0 If we proceed as you=E2=80=99re =
suggesting, a huge amount of writing will occur on StackOverflow,
 Medium, SlashDot, blogs, and other developer forums, where confused develo=
pers will ask =E2=80=9CWhy do I have to change my deployed code?=E2=80=9D w=
ith the answers being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=
=99s no need to change your deployed code.=E2=80=9D

=C2=A0<=
/u>


I=E2=80=99d gladl=
y write a few sentences in our new specs now to prevent ongoing confusion a=
nd interop problems that would otherwise result.=C2=A0 Let me know when you=
=E2=80=99re ready to incorporate them into the spec text.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com> 

Sent: Thursday, May 7, 2020 4:39 PM

To: Dick Hardt <dick.hardt@gmail.com>

Cc: OAuth WG <oauth@ietf.org>; Torsten Lodderstedt <torsten@lodderstedt.net>; Mike Jo=
nes <Mi=
chael.Jones@microsoft.com>

Subject: Re: OAuth 2.1 - require PKCE?




=C2=A0






Backing up a step or two, there's another point =
here that I think has been missed in these discussions.




=C2=A0






PKCE solves two problems: stolen authorization codes=
 for public clients, and authorization code injection for all clients. We&#=
39;ve only been talking about authorization code injection on the list so f=
ar. The quoted section of the security
 BCP (4.5.3) which says clients can do PKCE or use the nonce, is only talki=
ng about preventing authorization code injection.






=C2=A0






The nonce parameter solves authorization code inject=
ion if the client requests an ID token. Public clients using the nonce para=
meter are still susceptible to stolen authorization codes so they still nee=
d to do PKCE as well.






=C2=A0






The only case where OpenID Connect clients don't=
 benefit from PKCE is if they are also confidential clients. Public client =
OIDC clients still need to do PKCE even if they check the nonce.<=
/u>






=C2=A0






OpenID Connect servers working with confidential cli=
ents still benefit from PKCE because they can then enforce the authorizatio=
n code injection protection server-side=C2=A0rather=C2=A0than cross their f=
ingers that clients implemented the nonce check
 properly.






=C2=A0






I really don't think it's worth the amount o=
f explanation this will take in the future to write an exception into OAuth=
 2.1 or the Security BCP for only some types of OpenID Connect clients when=
 all clients would benefit from PKCE anyway.






=C2=A0






Aaron






=C2=A0








=C2=A0




=C2=A0






On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:










Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues that PKCE protects ag=
ainst. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence=C2=A0have support for PK=
CE if following best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7

















--000000000000b1030805a52eca02--


From nobody Sat May  9 09:39:08 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B355E3A0F1A for ; Sat,  9 May 2020 09:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C_aIypZtq4h for ; Sat,  9 May 2020 09:39:05 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15883A0F19 for ; Sat,  9 May 2020 09:39:04 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id z22so3917607lfd.0 for ; Sat, 09 May 2020 09:39:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=l1upHG6VDXXPCSuIJbJPbLyfH2E7AtmOXQyKHps/9a4=; b=lG8+LmFaf26nFJj40LWVy468Y3TikUx3PZmvG17EmuqN6YKJG9eYi0MeTvPeflb2EA 81XRDwr0JKQ7cP6Qe4IOCfr3EkkI2wvDk/1LeIKATapg8gJ/7JwcxZ82eCSovOLEGzGI 2C1jih9HhxO3j1RdSPTn6RlA7s1Sh2XAVcwM3TiSdAiGpzFCYY62OyoCoTmmTK0ilZnW ywCk8Mk9VmScIk2GjxbfH0g4uo5XLJZBXDrlnCq6p8HXzvgCv3MxK3sKR5nWIKc58r3D mXB7E3q9FRFjiswhW4FwcGdUlc41PUDcIMgUklu5E5D66JWSG3qN3sldklSJYS5HJyPV J3xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l1upHG6VDXXPCSuIJbJPbLyfH2E7AtmOXQyKHps/9a4=; b=CgtF2RREcvia4RF9GMEYkngnaZTQ3WGhlxV857jyuS4tPSNQZ+bP5KOuut3quMKdCy Ii9L7S2beFtvxAeb4nkxYNV4J4y1/VypBEo2iqasQ1hooISC66UPxGVKwHG42YaVg15k JVPHG/bKUOhuHidT9j+HOpbnFO/YgvBvw6tS78nJ1PeUFp80bexcXBIH5ethE8MQUrKn M1nMo3qeOBFX+oYu7lCnyoD4uroDWNdqIblaNDNP/dbU6pSJxKGeiJJRDAYrjumji0lo E5f3/gKUXCDtjr2wfgW74pmhbsbagMBrxhHAmBLPTmvX78NGaMWxHxjKX7x+KERfB31V 5tYA==
X-Gm-Message-State: AOAM5303g1uFOl68X0TBPS/78lgJhNXdjMFBUlxpWI2DmPsEZd2SgsPp HIlG5zdaoDDXpBwZdSTX7xJHEnX7G1Vj/siuGWh9m9KsI/E=
X-Google-Smtp-Source: ABdhPJzGqcyhtnZTvseDco0pgouhZIXHeMlDlG8LaW817BLmVObyJeaoA/V4XKrSkEHmvpjNYUJO30e1EFTFsgi/IxU=
X-Received: by 2002:ac2:5212:: with SMTP id a18mr5426771lfl.83.1589042343030;  Sat, 09 May 2020 09:39:03 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Sat, 9 May 2020 12:38:52 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000063b40205a539c03f"
Archived-At: 
Subject: [OAUTH-WG] A WGLC on "JWT Response for OAuth Token Introspection"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 May 2020 16:39:07 -0000

--00000000000063b40205a539c03f
Content-Type: text/plain; charset="UTF-8"

Hi,

This is a working group last call for "JWT Response for OAuth Token
Introspection".
This documented was returned to the WG after a number of  important changes
during the IESG review.

Here is the document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

Please send your comments to the OAuth mailing list by May 22, 2020.

Regards,
 Rifaat & Hannes

--00000000000063b40205a539c03f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--00000000000029350c05a550f4de--


From nobody Sun May 10 13:21:51 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6B13A0B8C for ; Sun, 10 May 2020 13:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmdT_sPMaU-y for ; Sun, 10 May 2020 13:21:48 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07F63A0B88 for ; Sun, 10 May 2020 13:21:47 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id yc10so4237989ejb.12 for ; Sun, 10 May 2020 13:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jYnFANQrsSAYjF9Rm7Y//yTDh9OPdAS8ZfIJk8foEKs=; b=nPeN8N80sy2dueU+fJbwxM6mq69eXP+lJ9Id1mxWr+NjyRuAzLuXOBLzvcGhMaPLhn kY82UFLHkwbRtLIC2gyMyYjah7jmBaDZ7+OBr+EecoGf3RKTd1TS5cTp+P9pqilOJ7fr Twzd6cJIfWPvd1z/EJd7sm3tf8lypzoolhozUQLekniwOf9urH3Z9xMXcE/DZcFq50GR 5rRlW/PadQKr1Pb6/jG+IdYfn7rq8jgmMb+Wb7IHO+dZrEQggwsL6UeuYn+GvE/P+YJH QCJnfFP8B0gqziq13N3if9Vq7bmhWX/paxRgTDXlJhZHfTbZpFF0rR4YIphSTpFPCbro cIDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jYnFANQrsSAYjF9Rm7Y//yTDh9OPdAS8ZfIJk8foEKs=; b=bD06ganyXOwsfGLQ/aGTlufmk/tQYGZSQoU4gYLoPtxZdHTjjm2v89WplVxvmFHKY6 uZvkZ9J7z1VJ+06qvjX+ORWtEtYxVJu3ea0VYnfFImgvmL1++LrjcHZZVRYDvZL0qdDy CeIsLE4B2TbT2YzwqaiybBT16WtDcsySbOCVLkaKr8vFeCZgh3tIVv1rUm8Xnc0ZFJ3N dyGdq23IxbTcAgNYz2WOqTa9XaVYP8kKfKO67OW17jqbftfFihCYWOZPUeHVOAqVXYJz Nt+67r5ST3p9CkAAcOkZ2hxGrQd7EZZ3/vsgUp3pzCtf4nqhK/2a2BbGqLCn2IpcqZ0Z xnfA==
X-Gm-Message-State: AGi0PuYdk5FL1TUoX4YSmLNgE6nYplWSU/QD40/fuUcL4Me0NfIFQSbM kdsU06AXyrsLGIq9uveRS4Yz7Od2Ulo1gFCkNO1NUSyO
X-Google-Smtp-Source: APiQypJVuGRgxh4jNx26uxb+1PTP2jRcZKVVHW4QBbpHkVil81UKcYg9ttkuLIFRb7cPH9J4vQoYJ281xAbq3iE3z1g=
X-Received: by 2002:a17:907:4272:: with SMTP id nq2mr10899225ejb.205.1589142106124;  Sun, 10 May 2020 13:21:46 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Jared Jennings 
Date: Sun, 10 May 2020 15:21:33 -0500
Message-ID: 
To: Mike Jones 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000bbbbed05a550faa5"
Archived-At: 
Subject: Re: [OAUTH-WG] Aligning PKCE requirements within the OAuth Security BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:21:50 -0000

--000000000000bbbbed05a550faa5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As a clarifying question, you are saying "Servers must support" and not
"Servers must require clients to use PKCE".

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Wed, May 6, 2020 at 4:04 PM Mike Jones  wrote:

> As is being discussed in the thread =E2=80=9C[OAUTH-WG] OAuth 2.1 - requi=
re
> PKCE?=E2=80=9D,
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2=
.1..1
> 
> has inconsistent requirements for PKCE support between clients and
> servers.  Per the first paragraph, clients must either use PKCE or use th=
e
> OpenID Connect nonce to prevent authorization code injection.  Whereas th=
e
> fourth paragraph says =E2=80=9C*Authorization servers MUST support PKCE [=
RFC7636]*.=E2=80=9D.
> This imposes a requirement on servers that isn=E2=80=99t present for corr=
esponding
> clients.  (I missed this internal discrepancy within the specification wh=
en
> I did my review.)
>
>
>
> I therefore request that the fourth paragraph by change to read: =E2=80=
=9C*OAuth
> Servers MUST support PKCE [RFC7636] unless they are only used for OpenID
> Connect Authentication Requests*=E2=80=9D, making the requirements on cli=
ents and
> servers parallel.  That way PKCE will still be there unless you don=E2=80=
=99t need
> it.  (And it still could be there if the server implementer chooses to ha=
ve
> it in all cases, but that should be their call.)
>
>
>
>                                                        Thank you,
>
>                                                        -- Mike
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000bbbbed05a550faa5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


As a clarifying question, you are saying "Servers mus=
t support" and not "Servers must require clients to use PKCE"=
;.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp:=
=C2=A0+1 816.678.4152


On Wed, May 6,=
 2020 at 4:04 PM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:











As is being discussed in the thread =E2=80=9C[OAUTH-=
WG] OAuth 2.1 - require PKCE?=E2=80=9D,

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1=
..1 has inconsistent requirements for PKCE support between clients and =
servers.=C2=A0 Per the first paragraph, clients must either use PKCE or use=
 the OpenID Connect nonce to prevent authorization
 code injection.=C2=A0 Whereas the fourth paragraph says =E2=80=9CAuthor=
ization servers MUST support PKCE [RFC7636].=E2=80=9D.=C2=A0 This impos=
es a requirement on servers that isn=E2=80=99t present for corresponding cl=
ients.=C2=A0 (I missed this internal discrepancy within the specification
 when I did my review.)


=C2=A0


I therefore request that the fourth paragraph by cha=
nge to read:
=E2=80=9COAuth Servers MUST support P=
KCE [RFC7636] unless they are only used for OpenID Connect Authentication R=
equests=E2=80=9D, making the requirements on clients and servers parall=
el.=C2=A0 That way PKCE will still be there unless you don=E2=80=99t
 need it.=C2=A0 (And it still could be there if the server implementer choo=
ses to have it in all cases, but that should be their call.)<=
/span>


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 Thank you,


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=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<=
/u>






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000bbbbed05a550faa5--


From nobody Sun May 10 13:22:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55D3A0B8C for ; Sun, 10 May 2020 13:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clkvLQw2nX2C for ; Sun, 10 May 2020 13:22:20 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650112.outbound.protection.outlook.com [40.107.65.112]) (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 AE2DB3A0B88 for ; Sun, 10 May 2020 13:22:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K40ia4HqltSKaVB4sBI9+bHqUzJoIW1TnS6ZypfIbb2sRpS2aNP5v6ZjvcLbwhRFC23uzCs9pujwngrqp/482lyq8WnrAghuP/xcLOkKucdj9rqVE32Z2733wewbGRgpDYuODMt0mX5XGYZeZ9W2/HDy5SnNDDt2PujxYs4q9HPXGU5lNN2YUGQVnFnV3/2ldroFPn24baHUij1egqEjK5JxqLBLtQOfqlnBX8P7ibeqU+g4OERQsGBbyn6JPWGUqKCinNhGYiWhbcViEySyJXGxaoNHYbqNAQy9neQZU9N0l4tIcMXW3EfQQ2E78Yjvw4LulXfQdm+IBt2AKaDolw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l5KJfV1h4MmNyL4agHNA/pi1UyHT+xMQNvwRqDauuko=; b=Og7Y13GLTvCfq2Dy6PZ8XC1xWOXpvd+rnUhfd6Uq36hceYOX0SzYSFOOQHh7qmv1UewRjWIgwDukOlsTSRtn8/aPTF213540JVFK+9BaJKSLG2qWVtlHKNGqHzEYX5hJTFqtglDjdRGPHRIxQ81KGqchMwssG4MQULEJayyV+fFOctQL88dZYxJEP41ZJ1ZJBt1/QGrFAhlIRoTDbSEUzZ96lDcqA7wMy4DAS0ilurmfWDC4mBzJ+a1vyfVcLW2igq2+gcBtZ4zJta/XshUjt7a2kLuxecUL/FL5v5IyCg5VVyOe3HyxNfCJ41iHUoQXWXuZkLSTyZvAym/Hl4eh2w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l5KJfV1h4MmNyL4agHNA/pi1UyHT+xMQNvwRqDauuko=; b=Y93n7+sXme5V89tcZZXeB+pmfhjUr7Te6NRB7jCYJYoUBPfhySXDhhcRz3ZEZ7d/AOm98NGQJiMbQ8d+LzdtE8MfWuoW/x9JtTIaHmLtduvUmRBde8VdSEJHZOR0dkCJghg8sX+w7W7HKcTPAizoOK1J98Jd9iqZZvukP/qpFOE=
Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0338.namprd00.prod.outlook.com (2603:10b6:207:1f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3032.0; Sun, 10 May 2020 20:22:02 +0000
Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073%7]) with mapi id 15.20.3031.000; Sun, 10 May 2020 20:22:02 +0000
From: Mike Jones 
To: Neil Madden , Dick Hardt 
CC: "oauth@ietf.org" , Torsten Lodderstedt 
Thread-Topic: OAuth 2.1 - require PKCE?
Thread-Index: AdYnCKiW6CWPC+2kRlKIzNDqlWwqaA==
Date: Sun, 10 May 2020 20:22:02 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=505760ae-24c3-40d8-a4b5-0000311c5064; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-10T20:20:42Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: forgerock.com; dkim=none (message not signed) header.d=none;forgerock.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3ee2cace-8f9c-4dcf-bafd-08d7f51fccb9
x-ms-traffictypediagnostic: BL0PR00MB0338:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 039975700A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3taaRrDLPx8sPCIB1atOWQ8PwpEAk21oyJZ2aike8F6ZmfFIaA6FbUQoOzm4SOc2O069Hqe3YL0QjWLsY9dvVuf04pRnz7JWeZRBqZiDXLA7DJDQGIjGVqq4/7lVB7hTZ7tPQLT21ccJA3mOpHClJjGColrPI2/OFLTYEOi/OL1QAlFkpObm9IKuYvs0nAwAe/Jn/iwhV0mcAUR0+hHfwM0ONutvn0KtKGXYOcd20ZtE4Mh9NzxJ0GheUqaC9Glbx412gTnUZj6alv576IZl7OwNSQ3SZncOLMbbPu1V0J137b8bpNG3F5pF0B7FVVMh8LKmlIq5O4j34Qoj+eC6TZXfNBLbtjnw783cJaoaKGPfGMY6hJCxnv1wwZCbOyVwF/v4hFlYARzxq1eRXYkv5B7aJdWECFc+Utytv6WV4EMaPkc3WScFxMv15WhcpdSWnC1D+pCRnEHFTa9jcy01ggmX9dtFurIeCDWtjM7Se3jk6MRmjKiwUDK+tUIR9uFCEDMf7wsBcTswWyxGSD76DQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(33430700001)(53546011)(66446008)(71200400001)(9686003)(76236002)(55016002)(6506007)(8990500004)(110136005)(10290500003)(316002)(54906003)(478600001)(66574014)(33440700001)(966005)(166002)(7696005)(52536014)(186003)(26005)(76116006)(33656002)(64756008)(66556008)(66476007)(82960400001)(82950400001)(66946007)(4326008)(2906002)(5660300002)(8676002)(8936002)(86362001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: vGbfkog7mdFoJfYWYNyKJD4NI1NN0gEdIWKTRHugcfVDCV8qHGAJ/ZJMejIJ89Wpnd697tREigI4stu61kYFIldg2txIiV6mluFzssQ8tn6as8h1iINeo08RjKR+OcBq3dNiM3ZGbI/Ojfcc4hqCUm1EbS7vLfmodARIUe/fZivNhwF/shSTz1ONNlBV2qAB7gdEyyHKJEf+rVcLSHtY4s3CWVLEEKeMGWqFevQN7CsTzhzjrHCiRTCRx6ZtNscVFiD86ar32AG6SiL4XJmgqLtK0ndmFCjXo+GIEGkvVcx5JMMG3LYM3YjGI1F3uOJJHel+Km3on/r3RQURU2Bw4kDtmzzecwgDt5VKuagogxSMLaoACWGBq0QI5HLNmet2zclXfyasSsISXuW8LJdy/3NGNkWNaU78OCBw/xsD5ldH0Pps5ICrJt8q6mDhbxefHlnXWdr65CcxKdFjA8Hp5ja0z6p1ikgmfvBB0AE2sgE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688CAFDA45BDF2883EF92B5F5A00MN2PR00MB0688namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ee2cace-8f9c-4dcf-bafd-08d7f51fccb9
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 20:22:02.1459 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zAikVVkN3aopNCB6Winyhzne37U0DZHbtVKASV3KrWzMUERlkbYrc7wUvFY+mvR487gUQzzUB0bC+clxhS2oGw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0338
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:22:23 -0000

--_000_MN2PR00MB0688CAFDA45BDF2883EF92B5F5A00MN2PR00MB0688namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RXhhY3RseSENCg0KSSBiZWxpZXZlIHRoYXQgdGhpcyBhbHNvIHRoZSBzYW1lIHBvaW50IHRoYXQg
QnJpYW4gQ2FtcGJlbGwgd2FzIG1ha2luZyBlYXJsaWVyIGFib3V0IGludGVyb3BlcmFiaWxpdHkg
aW1wbGljYXRpb25zLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5A
Zm9yZ2Vyb2NrLmNvbT4NClNlbnQ6IFN1bmRheSwgTWF5IDEwLCAyMDIwIDE6MDYgUE0NClRvOiBE
aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVs
LkpvbmVzQG1pY3Jvc29mdC5jb20+OyBvYXV0aEBpZXRmLm9yZzsgVG9yc3RlbiBMb2RkZXJzdGVk
dCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZTog
T0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPw0KDQpCdXQgaWYgYW4gQVMgdXBncmFkZXMgdG8gT0F1
dGggMi4xIHRoZW4gaXQgTVVTVCByZWplY3QgYXV0aG9yaXphdGlvbiByZXF1ZXN0cyB0aGF0IGRv
buKAmXQgaW5jbHVkZSBhIGNvZGVfY2hhbGxlbmdlIChzZWN0aW9uIDQuMS4yLjEpLCBzbyB0aGlz
IHdpbGwgb25seSBiZSBwb3NzaWJsZSB3aGVuIGFsbCBjbGllbnRzIHN1cHBvcnQgUEtDRS4NCg0K
VGhpcyBtYWtlcyBpdCBpbXBvc3NpYmxlIGZvciBhIDIuMS1jb21wbGlhbnQgQVMgdG8gYWxzbyBz
dXBwb3J0IG5vbi1QS0NFIDIuMCBjbGllbnRzIChpLmUuLCB0aGUgdmFzdCBtYWpvcml0eSBvZiB0
aGVtKS4NCg0KSSB0aGluayB3ZSBjYW4gaGF2ZSBhIDIuMSBzcGVjIHRoYXQgc2F5cyBjbGllbnRz
IGFuZCBzZXJ2ZXJzIE1VU1Qgc3VwcG9ydCBQS0NFIHdpdGhvdXQgdGhpcyBoYXJkLWZhaWwgY2xh
dXNlLiBPdGhlcndpc2UgSSBjYW7igJl0IHNlZSBob3cgd2XigJlkIGV2ZXIgc2hpcCB3aXRoIDIu
MS1jb21wbGlhbmNlIGVuYWJsZWQgb3V0LW9mLXRoZS1ib3guDQoNCuKAlCBOZWlsDQoNCk9uIDEw
IE1heSAyMDIwLCBhdCAyMDozOCwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFp
bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIE1pa2UsIEkgd291bGQgY29u
c2lkZXIgdXBncmFkaW5nIHRvIE9BdXRoIDIuMSB0byBiZSB2b2x1bnRhcnksIGp1c3QgYXMgdGhl
IG90aGVyIGV4dGVuc2lvbnMuIFNpbWlsYXJseSwgT0F1dGggMS4wIGRlcGxveW1lbnRzIHVwZ3Jh
ZGluZyB0byBPQXV0aCAyLjAgd2FzIHZvbHVudGFyeS4NCg0KV291bGQgeW91IGNsYXJpZnkgd2h5
IHlvdSB0aGluayB1cGdyYWRpbmcgdG8gT0F1dGggMi4xIHdvdWxkIGJlIG1hbmRhdG9yeT8NCg0K
DQpPbiBTdW4sIE1heSAxMCwgMjAyMCBhdCAxMjowMiBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv
bmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29t
QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJIGFncmVlIHdpdGggYWN0aXZlbHkgbWFpbnRhaW5p
bmcgYW5kIGltcHJvdmluZyB0aGUgT0F1dGggMi4wIHNwZWNzIGJ5IGFkZGluZyBlbmhhbmNlbWVu
dHMgdGhhdCBhcmUgdm9sdW50YXJ5IHRvIHVzZS4gIEnigJl2ZSB3b3JrZWQgb24gbWFueSBzdWNo
IGltcHJvdmVtZW50cywgaW5jbHVkaW5nIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiwgQXV0
aG9yaXphdGlvbiBNZXRhZGF0YSwgdGhlIERldmljZSBGbG93LCBUb2tlbiBFeGNoYW5nZSwgRFBv
UCwgYW5kIHN1cHBvcnQgUEFSIGFuZCBSQVIsIGV0Yy4gIFRoZSBpc3N1ZSB0aGF04oCZcyB0aGUg
c3ViamVjdCBpcyB0aGUgY3VycmVudCBkaXNjdXNzaW9uIGlzIHdoZXRoZXIgdG8gbWFrZSB1c2Ug
b2YgYW5vdGhlciBlbmhhbmNlbWVudCwgUEtDRSwgbWFuZGF0b3J5IGluIGNhc2VzIHdoZXJlIGl0
4oCZcyBhY3R1YWxseSBub3QgbmVlZGVkLCByYXRoZXIgdGhhbiBtYWtpbmcgaXRzIHVzZSB2b2x1
bnRhcnkgbGlrZSB0aGUgb3RoZXIgZW5oYW5jZW1lbnRzLCB3aGljaCBJIGNlcnRhaW5seSBzdXBw
b3J0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9k
ZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFy
Yy5pZXRmLm9yZz4+DQpTZW50OiBTdW5kYXksIE1heSAxMCwgMjAyMCAzOjE1IEFNDQpUbzogTWlr
ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IERhbmllbCBGZXR0IDxmZXR0QGRhbmllbGZldHQuZGU8bWFp
bHRvOmZldHRAZGFuaWVsZmV0dC5kZT4+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJl
cXVpcmUgUEtDRT8NCg0KSGkgTWlrZSwNCg0KTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lcz00MG1p
Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p
ZXRmLm9yZz4+IHNjaHJpZWIgYW0gRnIuIDguIE1haSAyMDIwIHVtIDE4OjU1Og0KT0F1dGggMi4x
IHdhcyBzdXBwb3NlZCB0byBub3QgaW50cm9kdWNlIGJyZWFraW5nIGNoYW5nZXMuDQpJIGNhbm5v
dCByZW1lbWJlciB0aGUgV0cgbWV0IHRoYXQgZGVjaXNpb24uIENhbiB5b3UgcGxlYXNlIHJlZmVy
IHRvIHRoZSByZXNwZWN0aXZlIHRocmVhZD8NCg0KUmVxdWlyaW5nIGV4YWN0IHJlZGlyZWN0IFVS
SSBtYXRjaGluZyBpcyBhbHJlYWR5IGEgYnJlYWtpbmcgY2hhbmdlLiBEbyB5b3Ugb3Bwb3NlIGFn
YWluc3QgdGhpcyBhcyB3ZWxsPw0KDQoNCklmIHlvdSB3YW50IHRvIGRvIHRoYXQsIHBsZWFzZSBk
byBpdCBpbiBUeEF1dGggaW5zdGVhZC4NCg0KSW50ZXJlc3Rpbmcgc3RhdGVtZW50LiBEb2VzIGl0
IG1lYW4geW91IHdhbnQgdG8gY29uc2VydmUgT0F1dGggMi4wIGFuZCBmb3JjZSBhbnkgZW5oYW5j
ZW1lbnRzL2ltcHJvdmVtZW50cyB0byBnbyBpbnRvIFRYQXV0aD8gVGhpcyB3b3VsZCBjYXVzZSBo
dWdlIG1pZ3JhdGlvbiBlZmZvcnRzIGZvciBleGlzdGluZyBkZXBsb3ltZW50cyB3YW50aW5nIHRv
IGJlbmVmaXQgZnJvbSB0aG9zZSBlbmhhbmNlbWVudHMuDQoNCkkgdGhpbmsgZXhpc3RpbmcgZGVw
bG95bWVudHMgYXJlIGJldHRlciBzZXJ2ZWQgYnkgYWN0aXZlbHkgbWFpbnRhaW5pbmcgYW5kIGV2
b2x2aW5nIHRoZSAyLnggbGluZS4gRm9yIGV4YW1wbGUsIFBBUiBhbmQgUkFSIGFyZSBhdHRlbXB0
cyB0byBpbXByb3ZlIE9BdXRoIDIueCBhbmQgbWFrZSBpdCB1c2FibGUgZm9yIG5ldyB1c2UgY2Fz
ZXMuIFRoYXTigJlzIGJldHRlciBwcm90ZWN0aW9uIG9mIGV4aXN0aW5nIGludmVzdG1lbnRzIHRo
YW4gc2VuZGluZyB0aGVtIG9mIHRvIFRYQXV0aC4NCktpbmQgcmVnYXJkcywNClRvcnN0ZW4uDQoN
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRGFuaWVsIEZldHQNClNlbnQ6IFRo
dXJzZGF5LCBNYXkgNywgMjAyMCAxMTo1MCBQTQ0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpv
YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVp
cmUgUEtDRT8NCg0KKzEgdG8gYWxsIHdoYXQgQWFyb24gc2FpZC4gVGhhbmtzIGZvciBwb2ludGlu
ZyB0aGlzIG91dCENCg0KV2UgbmVlZCB0byBhZGRyZXNzIHRoaXMgaW4gdGhlIHNlY3VyaXR5IEJD
UCBhbmQgdGhpcyB3aWxsIGJlIGEgbm9ybWF0aXZlIGNoYW5nZSB0aGF0IGFmZmVjdHMgT3BlbklE
IENvbm5lY3QgQ29yZSAoanVzdCBhcyBvdXIgY3VycmVudCByZWNvbW1lbmRhdGlvbiBvbiB0aGUg
dXNhZ2Ugb2Ygbm9uY2UpLg0KDQpXZSB3b3VsZCB0aGVuIGhhdmU6DQoNCi0gdXNlIFBLQ0UsIGV4
Y2VwdCBpZiB5b3UgdXNlIE9JREMgd2l0aCBhIG5vbmNlLCB0aGVuIHlvdSBkb24ndCBuZWVkIFBL
Q0UsIGV4Y2VwdCBpZiB5b3UgYXJlIGEgcHVibGljIGNsaWVudCwgdGhlbiB5b3Ugc3RpbGwgbmVl
ZCBQS0NFLg0KLSB1c2Ugc3RhdGUsIGV4Y2VwdCBpZiB5b3UgdXNlIFBLQ0UsIHRoZW4geW91IGRv
bid0IG5lZWQgc3RhdGUuDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHZlcnkgZ29vZCByZWFzb25zIHRv
IHNpbXBsaWZ5IHRoaXMgZG93biB0bw0KDQotIHVzZSBQS0NFDQotIHlvdSBtYXkgb3IgbWF5IG5v
dCB1c2Ugc3RhdGUNCg0KRmlyc3QgYW5kIGZvcmVtb3N0LCBub3QgbWFueSBwZW9wbGUgd2lsbCB1
bmRlcnN0YW5kIHdoeSB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUgQkNQL09BdXRoIDIuMSBtYW5k
YXRlIFBLQ0UgYW5kIHNvbWUgd2hlcmUgdGhleSBkb24ndC4gSG93ZXZlciwgdW5kZXJzdGFuZGlu
ZyB3aHkgeW91IGhhdmUgdG8gZG8gc29tZXRoaW5nIGlzIGtleSB0byBjb21wbGlhbmNlLiBUaGUg
c2hvcnQgdmVyc2lvbiAiUEtDRSBwcm90ZWN0cyB0aGUgY29kZTsgdGhlcmUgaXMgYSBzcGVjaWZp
YyBjYXNlIHdoZXJlIGl0IGlzIG5vdCBuZWVkZWQsIGJ1dCBpdHMgYmV0dGVyIHRvIHVzZSBpdCBh
bGwgdGhlIHRpbWUiIGlzIGVhc3kgdG8gdW5kZXJzdGFuZC4gV2Ugd2lsbCBub3Qgc2VlIG1hbnkg
aW1wbGVtZW50YXRpb25zIGZvbGxvd2luZyB0aGUgbG9uZyB2ZXJzaW9uIGFib3ZlIGNvcnJlY3Rs
eS4NCg0KU2Vjb25kLCB3ZSBkcmFtYXRpY2FsbHkgcmVkdWNlIHRlY2huaWNhbCBjb21wbGV4aXR5
IGJ5IHJlZHVjaW5nIGNhc2VzIHRoYXQgbmVlZCB0byBiZSBoYW5kbGVkLiBXZSByZWR1Y2UgY29y
cmVjdG5lc3MgYW5kIGNvbXBsaWFuY2UgdGVzdGluZyBjb21wbGV4aXR5IGluIHRoZSBzYW1lIHdh
eS4gV2UgcmVkdWNlIHRoZSBjb3N0IG9mIHNlY3VyaXR5IGFuYWx5c2lzLCB3aGljaCBzY2FsZXMg
cmVhbGx5IGJhZGx5IHRvIG1vcmUgY2FzZXMuDQoNCkFuZCBmaW5hbGx5LCB1c2luZyBub25jZSB0
byBwcm90ZWN0IGFnYWluc3QgY29kZSBpbmplY3Rpb24gaXMgbGVzcyByb2J1c3QgdGhhbiBQS0NF
LiBBUyBoYXZlIGEgYmV0dGVyIHRyYWNrIHJlY29yZCB0aGFuIGNsaWVudHMgd2hlbiBpdCBjb21l
cyB0byBjb3JyZWN0bHkgaW1wbGVtZW50aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQoNClllcywg
dGhpcyB3aWxsIG1ha2UgYSBudW1iZXIgb2YgaW1wbGVtZW50YXRpb25zIG5vbi1zcGVjLWNvbXBs
aWFudCwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBhIGh1Z2UgcHJvYmxlbS4gU29m
dHdhcmUgbmVlZHMgdG8gYWRhcHQgYWxsIHRoZSB0aW1lIGFuZCBhIHNvZnR3YXJlIHRoYXQgaGFz
IG5vdCBiZWVuIGNoYW5nZWQgaW4gYSB3aGlsZSBpcyBwcm9iYWJseSBub3Qgb25lIHlvdSB3b3Vs
ZCB3YW50IHRvIHVzZSBhbnl3YXkuIFdlIGFyZSBzZXR0aW5nIGEgbmV3IGdvYWwgZm9yIGltcGxl
bWVudGF0aW9ucyB0byBtZWV0IGFuZCBldmVudHVhbGx5LCBtYWludGFpbmVkIGltcGxlbWVudGF0
aW9ucyB3aWxsIGdldCB0aGVyZS4NCg0KLURhbmllbA0KDQoNCkFtIDA4LjA1LjIwIHVtIDAxOjM4
IHNjaHJpZWIgQWFyb24gUGFyZWNraToNCkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUn
cyBhbm90aGVyIHBvaW50IGhlcmUgdGhhdCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVz
ZSBkaXNjdXNzaW9ucy4NCg0KUEtDRSBzb2x2ZXMgdHdvIHByb2JsZW1zOiBzdG9sZW4gYXV0aG9y
aXphdGlvbiBjb2RlcyBmb3IgcHVibGljIGNsaWVudHMsIGFuZCBhdXRob3JpemF0aW9uIGNvZGUg
aW5qZWN0aW9uIGZvciBhbGwgY2xpZW50cy4gV2UndmUgb25seSBiZWVuIHRhbGtpbmcgYWJvdXQg
YXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBvbiB0aGUgbGlzdCBzbyBmYXIuIFRoZSBxdW90
ZWQgc2VjdGlvbiBvZiB0aGUgc2VjdXJpdHkgQkNQICg0LjUuMykgd2hpY2ggc2F5cyBjbGllbnRz
IGNhbiBkbyBQS0NFIG9yIHVzZSB0aGUgbm9uY2UsIGlzIG9ubHkgdGFsa2luZyBhYm91dCBwcmV2
ZW50aW5nIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uDQoNClRoZSBub25jZSBwYXJhbWV0
ZXIgc29sdmVzIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gaWYgdGhlIGNsaWVudCByZXF1
ZXN0cyBhbiBJRCB0b2tlbi4gUHVibGljIGNsaWVudHMgdXNpbmcgdGhlIG5vbmNlIHBhcmFtZXRl
ciBhcmUgc3RpbGwgc3VzY2VwdGlibGUgdG8gc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgc28g
dGhleSBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgYXMgd2VsbC4NCg0KVGhlIG9ubHkgY2FzZSB3aGVy
ZSBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIGRvbid0IGJlbmVmaXQgZnJvbSBQS0NFIGlzIGlmIHRo
ZXkgYXJlIGFsc28gY29uZmlkZW50aWFsIGNsaWVudHMuIFB1YmxpYyBjbGllbnQgT0lEQyBjbGll
bnRzIHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBldmVuIGlmIHRoZXkgY2hlY2sgdGhlIG5vbmNlLg0K
DQpPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIHdvcmtpbmcgd2l0aCBjb25maWRlbnRpYWwgY2xpZW50
cyBzdGlsbCBiZW5lZml0IGZyb20gUEtDRSBiZWNhdXNlIHRoZXkgY2FuIHRoZW4gZW5mb3JjZSB0
aGUgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBwcm90ZWN0aW9uIHNlcnZlci1zaWRlIHJh
dGhlciB0aGFuIGNyb3NzIHRoZWlyIGZpbmdlcnMgdGhhdCBjbGllbnRzIGltcGxlbWVudGVkIHRo
ZSBub25jZSBjaGVjayBwcm9wZXJseS4NCg0KSSByZWFsbHkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0
aCB0aGUgYW1vdW50IG9mIGV4cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtlIGluIHRoZSBmdXR1cmUg
dG8gd3JpdGUgYW4gZXhjZXB0aW9uIGludG8gT0F1dGggMi4xIG9yIHRoZSBTZWN1cml0eSBCQ1Ag
Zm9yIG9ubHkgc29tZSB0eXBlcyBvZiBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIHdoZW4gYWxsIGNs
aWVudHMgd291bGQgYmVuZWZpdCBmcm9tIFBLQ0UgYW55d2F5Lg0KDQpBYXJvbg0KDQoNCg0KT24g
V2VkLCBNYXkgNiwgMjAyMCBhdCAxMDo0OCBBTSBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls
LmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkhlbGxvIQ0KDQpXZSB3
b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUgZmxvd3Mu
IFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29tbW9uIGlu
IE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9mIHRoZSBp
c3N1ZXMgdGhhdCBQS0NFIHByb3RlY3RzIGFnYWluc3QuIFdlIHRoaW5rIHRoYXQgbW9zdCBPcGVu
SUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBzdXBwb3J0IE9BdXRoIDIuMCwgYW5kIGhl
bmNlIGhhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMuDQoN
ClRoZSBhZHZhbnRhZ2VzIG9yIHJlcXVpcmluZyBQS0NFIGFyZToNCg0KLSBhIHNpbXBsZXIgcHJv
Z3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHByb2ZpbGVz
IGFzIHRoZXkgYWxsIHVzZSBQS0NFDQoNCi0gcmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3aGVuIHVz
aW5nICBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlmaWVyIGlzIHNlbnQgdGhyb3Vn
aCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZhbHVlDQoNCi0gZW5mb3Jj
ZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUgZm9yIGNs
aWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25kdWN0ZWQN
Cg0KV2hhdCBhcmUgZGlzYWR2YW50YWdlcyBiZXNpZGVzIHRoZSBwb3RlbnRpYWwgaW1wYWN0IHRv
IE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlmaWNhbnQgaXMgdGhhdCBpbXBh
Y3Q/DQoNCkRpY2ssIEFhcm9uLCBhbmQgVG9yc3Rlbg0KDQrhkKcNCg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QN
Cg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNClto
dHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5i
V0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9ZTEwOTljYTYtY2U0OS00OTk3LWJk
ZTMtNTM0ZDIyNTgyZWViXeGQpw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KDQo=

--_000_MN2PR00MB0688CAFDA45BDF2883EF92B5F5A00MN2PR00MB0688namp_
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
bWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz
O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw
LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu
OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t
LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N
CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s
PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs
aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5FeGFjdGx5ITxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBiZWxpZXZlIHRoYXQgdGhpcyBhbHNvIHRoZSBzYW1l
IHBvaW50IHRoYXQgQnJpYW4gQ2FtcGJlbGwgd2FzIG1ha2luZyBlYXJsaWVyIGFib3V0IGludGVy
b3BlcmFiaWxpdHkgaW1wbGljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw
MjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBOZWls
IE1hZGRlbiAmbHQ7bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8
L2I+IFN1bmRheSwgTWF5IDEwLCAyMDIwIDE6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IERpY2sgSGFy
ZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25l
cyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozsgb2F1dGhAaWV0Zi5vcmc7IFRv
cnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0Ozxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZTogT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NF
PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGlmIGFuIEFTIHVw
Z3JhZGVzIHRvIE9BdXRoIDIuMSB0aGVuIGl0IE1VU1QgcmVqZWN0IGF1dGhvcml6YXRpb24gcmVx
dWVzdHMgdGhhdCBkb27igJl0IGluY2x1ZGUgYSBjb2RlX2NoYWxsZW5nZSAoc2VjdGlvbiA0LjEu
Mi4xKSwgc28gdGhpcyB3aWxsIG9ubHkgYmUgcG9zc2libGUgd2hlbiBhbGwgY2xpZW50cyBzdXBw
b3J0IFBLQ0UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGlzIG1ha2VzIGl0IGltcG9zc2libGUgZm9yIGEgMi4xLWNvbXBsaWFudCBBUyB0byBhbHNvIHN1
cHBvcnQgbm9uLVBLQ0UgMi4wIGNsaWVudHMgKGkuZS4sIHRoZSB2YXN0IG1ham9yaXR5IG9mIHRo
ZW0pLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkkgdGhpbmsgd2UgY2FuIGhhdmUgYSAyLjEgc3BlYyB0aGF0IHNheXMgY2xpZW50cyBhbmQgc2Vy
dmVycyBNVVNUIHN1cHBvcnQgUEtDRSB3aXRob3V0IHRoaXMgaGFyZC1mYWlsIGNsYXVzZS4gT3Ro
ZXJ3aXNlIEkgY2Fu4oCZdCBzZWUgaG93IHdl4oCZZCBldmVyIHNoaXAgd2l0aCAyLjEtY29tcGxp
YW5jZSBlbmFibGVkIG91dC1vZi10aGUtYm94LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJQgTmVpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMCBNYXkgMjAyMCwg
YXQgMjA6MzgsIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWls
LmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNaWtlLCBJIHdvdWxkIGNv
bnNpZGVyIHVwZ3JhZGluZyB0byBPQXV0aCAyLjEgdG8gYmUgdm9sdW50YXJ5LCBqdXN0IGFzIHRo
ZSBvdGhlciBleHRlbnNpb25zLiBTaW1pbGFybHksIE9BdXRoIDEuMCBkZXBsb3ltZW50cyB1cGdy
YWRpbmcgdG8gT0F1dGggMi4wIHdhcyB2b2x1bnRhcnkuJm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3VsZCB5b3UgY2xhcmlmeSB3aHkgeW91IHRo
aW5rIHVwZ3JhZGluZyZuYnNwO3RvIE9BdXRoIDIuMSB3b3VsZCBiZSBtYW5kYXRvcnk/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3Vu
LCBNYXkgMTAsIDIwMjAgYXQgMTI6MDIgUE0gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz08
YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIj40MG1pY3Jvc29m
dC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBhZ3JlZSB3aXRoIGFjdGl2ZWx5IG1haW50YWluaW5n
IGFuZCBpbXByb3ZpbmcgdGhlIE9BdXRoIDIuMCBzcGVjcyBieSBhZGRpbmcgZW5oYW5jZW1lbnRz
IHRoYXQgYXJlIHZvbHVudGFyeSB0byB1c2UuJm5ic3A7IEnigJl2ZSB3b3JrZWQgb24gbWFueSBz
dWNoIGltcHJvdmVtZW50cywNCiBpbmNsdWRpbmcgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u
LCBBdXRob3JpemF0aW9uIE1ldGFkYXRhLCB0aGUgRGV2aWNlIEZsb3csIFRva2VuIEV4Y2hhbmdl
LCBEUG9QLCBhbmQgc3VwcG9ydCBQQVIgYW5kIFJBUiwgZXRjLiZuYnNwOyBUaGUgaXNzdWUgdGhh
dOKAmXMgdGhlIHN1YmplY3QgaXMgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiBpcyB3aGV0aGVyIHRv
IG1ha2UgdXNlIG9mIGFub3RoZXIgZW5oYW5jZW1lbnQsIFBLQ0UsIG1hbmRhdG9yeSBpbiBjYXNl
cw0KIHdoZXJlIGl04oCZcyBhY3R1YWxseSBub3QgbmVlZGVkLCByYXRoZXIgdGhhbiBtYWtpbmcg
aXRzIHVzZSB2b2x1bnRhcnkgbGlrZSB0aGUgb3RoZXIgZW5oYW5jZW1lbnRzLCB3aGljaCBJIGNl
cnRhaW5seSBzdXBwb3J0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6
IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gVG9yc3RlbiBMb2Rk
ZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1h
cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRm
Lm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXkgMTAsIDIwMjAgMzox
NSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBEYW5pZWwgRmV0dCAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmZldHRAZGFuaWVsZmV0dC5kZSIgdGFyZ2V0PSJfYmxhbmsiPmZldHRAZGFuaWVs
ZmV0dC5kZTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5B
TF0gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIE1pa2UsPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWlr
ZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29t
QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll
dGYub3JnPC9hPiZndDsgc2NocmllYiBhbSBGci4gOC4gTWFpIDIwMjAgdW0gMTg6NTU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxl
ZnQ6NC4uOHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iY29sb3I6IzAwMjA2MCI+T0F1dGggMi4xIHdhcyBzdXBwb3NlZCB0byBub3QgaW50cm9k
dWNlIGJyZWFraW5nIGNoYW5nZXMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg
Y2Fubm90IHJlbWVtYmVyIHRoZSBXRyBtZXQgdGhhdCBkZWNpc2lvbi4gQ2FuIHlvdSBwbGVhc2Ug
cmVmZXIgdG8gdGhlIHJlc3BlY3RpdmUgdGhyZWFkPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVxdWlyaW5nIGV4YWN0IHJl
ZGlyZWN0IFVSSSBtYXRjaGluZyBpcyBhbHJlYWR5IGEgYnJlYWtpbmcgY2hhbmdlLiBEbyB5b3Ug
b3Bwb3NlIGFnYWluc3QgdGhpcyBhcyB3ZWxsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NC4uOHB0Ij4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw
MjA2MCI+SWYgeW91IHdhbnQgdG8gZG8gdGhhdCwgcGxlYXNlIGRvIGl0IGluIFR4QXV0aCBpbnN0
ZWFkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW50ZXJlc3Rpbmcgc3RhdGVtZW50
LiBEb2VzIGl0IG1lYW4geW91IHdhbnQgdG8gY29uc2VydmUgT0F1dGggMi4wIGFuZCBmb3JjZSBh
bnkgZW5oYW5jZW1lbnRzL2ltcHJvdmVtZW50cyB0byBnbyBpbnRvIFRYQXV0aD8gVGhpcyB3b3Vs
ZCBjYXVzZSBodWdlIG1pZ3JhdGlvbiBlZmZvcnRzIGZvciBleGlzdGluZw0KIGRlcGxveW1lbnRz
IHdhbnRpbmcgdG8gYmVuZWZpdCBmcm9tIHRob3NlIGVuaGFuY2VtZW50cy48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgZXhp
c3RpbmcgZGVwbG95bWVudHMgYXJlIGJldHRlciBzZXJ2ZWQgYnkgYWN0aXZlbHkgbWFpbnRhaW5p
bmcgYW5kIGV2b2x2aW5nIHRoZSAyLnggbGluZS4gRm9yIGV4YW1wbGUsIFBBUiBhbmQgUkFSIGFy
ZSBhdHRlbXB0cyB0byBpbXByb3ZlIE9BdXRoIDIueCBhbmQgbWFrZSBpdCB1c2FibGUgZm9yDQog
bmV3IHVzZSBjYXNlcy4gVGhhdOKAmXMgYmV0dGVyIHByb3RlY3Rpb24gb2YgZXhpc3RpbmcgaW52
ZXN0bWVudHMgdGhhbiBzZW5kaW5nIHRoZW0gb2YgdG8gVFhBdXRoLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5LaW5kIHJlZ2FyZHMsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvcnN0ZW4u
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0
O21hcmdpbi1sZWZ0OjQuLjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw
MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IE9BdXRoICZs
dDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYW5p
ZWwgRmV0dDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDcsIDIwMjAgMTE6NTAgUE08
YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI
LVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MSB0byBhbGwgd2hhdCBBYXJvbiBzYWlkLiBU
aGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgbmVlZCB0byBhZGRyZXNzIHRoaXMgaW4g
dGhlIHNlY3VyaXR5IEJDUCBhbmQgdGhpcyB3aWxsIGJlIGEgbm9ybWF0aXZlIGNoYW5nZSB0aGF0
IGFmZmVjdHMgT3BlbklEIENvbm5lY3QgQ29yZSAoanVzdCBhcyBvdXIgY3VycmVudCByZWNvbW1l
bmRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2Ygbm9uY2UpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2Ugd291bGQgdGhlbiBoYXZlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB1
c2UgUEtDRSwgZXhjZXB0IGlmIHlvdSB1c2UgT0lEQyB3aXRoIGEgbm9uY2UsIHRoZW4geW91IGRv
bid0IG5lZWQgUEtDRSwgZXhjZXB0IGlmIHlvdSBhcmUgYSBwdWJsaWMgY2xpZW50LCB0aGVuIHlv
dSBzdGlsbCBuZWVkIFBLQ0UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPi0gdXNlIHN0YXRlLCBleGNlcHQgaWYgeW91IHVzZSBQS0NFLCB0aGVu
IHlvdSBkb24ndCBuZWVkIHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGVyZSBhcmUgdmVyeSBnb29kIHJlYXNv
bnMgdG8gc2ltcGxpZnkgdGhpcyBkb3duIHRvDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gdXNlIFBLQ0U8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB5b3UgbWF5IG9yIG1heSBu
b3QgdXNlIHN0YXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5GaXJzdCBhbmQgZm9yZW1vc3QsIG5vdCBtYW55IHBlb3BsZSB3aWxsIHVu
ZGVyc3RhbmQgd2h5IHRoZXJlIGFyZSBjYXNlcyB3aGVuIHRoZSBCQ1AvT0F1dGggMi4xIG1hbmRh
dGUgUEtDRSBhbmQgc29tZSB3aGVyZSB0aGV5IGRvbid0LiBIb3dldmVyLCB1bmRlcnN0YW5kaW5n
DQo8aT53aHk8L2k+IHlvdSBoYXZlIHRvIGRvIHNvbWV0aGluZyBpcyBrZXkgdG8gY29tcGxpYW5j
ZS4gVGhlIHNob3J0IHZlcnNpb24gJnF1b3Q7UEtDRSBwcm90ZWN0cyB0aGUgY29kZTsgdGhlcmUg
aXMgYSBzcGVjaWZpYyBjYXNlIHdoZXJlIGl0IGlzIG5vdCBuZWVkZWQsIGJ1dCBpdHMgYmV0dGVy
IHRvIHVzZSBpdCBhbGwgdGhlIHRpbWUmcXVvdDsgaXMgZWFzeSB0byB1bmRlcnN0YW5kLiBXZSB3
aWxsIG5vdCBzZWUgbWFueSBpbXBsZW1lbnRhdGlvbnMgZm9sbG93aW5nDQogdGhlIGxvbmcgdmVy
c2lvbiBhYm92ZSBjb3JyZWN0bHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWNvbmQsIHdlIGRyYW1hdGljYWxseSByZWR1Y2UgdGVj
aG5pY2FsIGNvbXBsZXhpdHkgYnkgcmVkdWNpbmcgY2FzZXMgdGhhdCBuZWVkIHRvIGJlIGhhbmRs
ZWQuIFdlIHJlZHVjZSBjb3JyZWN0bmVzcyBhbmQgY29tcGxpYW5jZSB0ZXN0aW5nIGNvbXBsZXhp
dHkgaW4gdGhlIHNhbWUgd2F5LiBXZSByZWR1Y2UNCiB0aGUgY29zdCBvZiBzZWN1cml0eSBhbmFs
eXNpcywgd2hpY2ggc2NhbGVzIHJlYWxseSBiYWRseSB0byBtb3JlIGNhc2VzLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIGZpbmFs
bHksIHVzaW5nIG5vbmNlIHRvIHByb3RlY3QgYWdhaW5zdCBjb2RlIGluamVjdGlvbiBpcyBsZXNz
IHJvYnVzdCB0aGFuIFBLQ0UuIEFTIGhhdmUgYSBiZXR0ZXIgdHJhY2sgcmVjb3JkIHRoYW4gY2xp
ZW50cyB3aGVuIGl0IGNvbWVzIHRvIGNvcnJlY3RseSBpbXBsZW1lbnRpbmcgc2VjdXJpdHkNCiBt
ZWNoYW5pc21zLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPlllcywgdGhpcyB3aWxsIG1ha2UgYSBudW1iZXIgb2YgaW1wbGVtZW50YXRp
b25zIG5vbi1zcGVjLWNvbXBsaWFudCwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBh
IGh1Z2UgcHJvYmxlbS4gU29mdHdhcmUgbmVlZHMgdG8gYWRhcHQgYWxsIHRoZSB0aW1lIGFuZCBh
IHNvZnR3YXJlIHRoYXQgaGFzDQogbm90IGJlZW4gY2hhbmdlZCBpbiBhIHdoaWxlIGlzIHByb2Jh
Ymx5IG5vdCBvbmUgeW91IHdvdWxkIHdhbnQgdG8gdXNlIGFueXdheS4gV2UgYXJlIHNldHRpbmcg
YSBuZXcgZ29hbCBmb3IgaW1wbGVtZW50YXRpb25zIHRvIG1lZXQgYW5kIGV2ZW50dWFsbHksIG1h
aW50YWluZWQgaW1wbGVtZW50YXRpb25zIHdpbGwgZ2V0IHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LURhbmllbDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFt
IDA4LjA1LjIwIHVtIDAxOjM4IHNjaHJpZWIgQWFyb24gUGFyZWNraTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmFja2luZyB1
cCBhIHN0ZXAgb3IgdHdvLCB0aGVyZSdzIGFub3RoZXIgcG9pbnQgaGVyZSB0aGF0IEkgdGhpbmsg
aGFzIGJlZW4gbWlzc2VkIGluIHRoZXNlIGRpc2N1c3Npb25zLg0KPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UEtDRSBzb2x2ZXMgdHdvIHByb2JsZW1z
OiBzdG9sZW4gYXV0aG9yaXphdGlvbiBjb2RlcyBmb3IgcHVibGljIGNsaWVudHMsIGFuZCBhdXRo
b3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGZvciBhbGwgY2xpZW50cy4gV2UndmUgb25seSBiZWVu
IHRhbGtpbmcgYWJvdXQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbg0KIG9uIHRoZSBsaXN0
IHNvIGZhci4gVGhlIHF1b3RlZCBzZWN0aW9uIG9mIHRoZSBzZWN1cml0eSBCQ1AgKDQuNS4zKSB3
aGljaCBzYXlzIGNsaWVudHMgY2FuIGRvIFBLQ0Ugb3IgdXNlIHRoZSBub25jZSwgaXMgb25seSB0
YWxraW5nIGFib3V0IHByZXZlbnRpbmcgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbi48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo
ZSBub25jZSBwYXJhbWV0ZXIgc29sdmVzIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gaWYg
dGhlIGNsaWVudCByZXF1ZXN0cyBhbiBJRCB0b2tlbi4gUHVibGljIGNsaWVudHMgdXNpbmcgdGhl
IG5vbmNlIHBhcmFtZXRlciBhcmUgc3RpbGwgc3VzY2VwdGlibGUgdG8gc3RvbGVuIGF1dGhvcml6
YXRpb24NCiBjb2RlcyBzbyB0aGV5IHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBhcyB3ZWxsLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl
IG9ubHkgY2FzZSB3aGVyZSBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIGRvbid0IGJlbmVmaXQgZnJv
bSBQS0NFIGlzIGlmIHRoZXkgYXJlIGFsc28gY29uZmlkZW50aWFsIGNsaWVudHMuIFB1YmxpYyBj
bGllbnQgT0lEQyBjbGllbnRzIHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBldmVuIGlmIHRoZXkgY2hl
Y2sNCiB0aGUgbm9uY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5PcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIHdvcmtpbmcgd2l0aCBjb25m
aWRlbnRpYWwgY2xpZW50cyBzdGlsbCBiZW5lZml0IGZyb20gUEtDRSBiZWNhdXNlIHRoZXkgY2Fu
IHRoZW4gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBwcm90ZWN0aW9u
IHNlcnZlci1zaWRlJm5ic3A7cmF0aGVyJm5ic3A7dGhhbg0KIGNyb3NzIHRoZWlyIGZpbmdlcnMg
dGhhdCBjbGllbnRzIGltcGxlbWVudGVkIHRoZSBub25jZSBjaGVjayBwcm9wZXJseS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgcmVh
bGx5IGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdGhlIGFtb3VudCBvZiBleHBsYW5hdGlvbiB0aGlz
IHdpbGwgdGFrZSBpbiB0aGUgZnV0dXJlIHRvIHdyaXRlIGFuIGV4Y2VwdGlvbiBpbnRvIE9BdXRo
IDIuMSBvciB0aGUgU2VjdXJpdHkgQkNQIGZvciBvbmx5IHNvbWUgdHlwZXMgb2YgT3BlbklEIENv
bm5lY3QNCiBjbGllbnRzIHdoZW4gYWxsIGNsaWVudHMgd291bGQgYmVuZWZpdCBmcm9tIFBLQ0Ug
YW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+QWFyb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMDo0OCBBTSBE
aWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdl
dD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZWxsbyENCjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIHdvdWxkIGxp
a2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29kZSBmbG93cy4gVGhpcyBp
cyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBjb21tb24gaW4gT3BlbklE
IENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUgb2YgdGhlIGlzc3Vlcw0K
IHRoYXQgUEtDRSBwcm90ZWN0cyBhZ2FpbnN0LiBXZSB0aGluayB0aGF0IG1vc3QgT3BlbklEIENv
bm5lY3QgaW1wbGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBoZW5jZSZu
YnNwO2hhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U
aGUgYWR2YW50YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIGEgc2ltcGxlciBwcm9ncmFt
bWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0aW9ucyBhbmQgcHJvZmlsZXMgYXMg
dGhleSBhbGwgdXNlIFBLQ0U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPi0gcmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3aGVuIHVzaW5nJm5i
c3A7IFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZpZXIgaXMgc2VudCB0aHJvdWdo
IHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQgdmFsdWU8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gZW5mb3JjZW1l
bnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUgZm9yIGNsaWVu
dCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25kdWN0ZWQ8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldo
YXQgYXJlIGRpc2FkdmFudGFnZXMgYmVzaWRlcyB0aGUgcG90ZW50aWFsIGltcGFjdCB0byBPcGVu
SUQgQ29ubmVjdCBkZXBsb3ltZW50cz8gSG93IHNpZ25pZmljYW50IGlzIHRoYXQgaW1wYWN0Pzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
RGljaywgQWFyb24sIGFuZCBUb3JzdGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGltZyBib3JkZXI9IjAi
IHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hlaWdodDouMDEwNGlu
IiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90
P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250
ZW50JmFtcDtndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5LWIyODQ3NDRiYzE3MSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1
dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286
cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8v
bWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVq
YjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPWUxMDk5Y2E2LWNlNDktNDk5Ny1i
ZGUzLTUzNGQyMjU4MmVlYiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls
eTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlz
dDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+
PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_MN2PR00MB0688CAFDA45BDF2883EF92B5F5A00MN2PR00MB0688namp_--


From nobody Sun May 10 13:24:08 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149BB3A0B8C for ; Sun, 10 May 2020 13:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQUGaVmwKiQk for ; Sun, 10 May 2020 13:24:02 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640136.outbound.protection.outlook.com [40.107.64.136]) (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 0EB703A0B8B for ; Sun, 10 May 2020 13:24:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NdRGdwdqouNvznRSFH0RZM13y7d8MHH+53uMKZucLqPAV/fUo/SCn26qrCx+X0MovGZLDtmtxwUlmXzSdc6XwQm8YBi+PVc9vmp6QmbkVf8R3jgcR3dsrfVepKedKaqw4fN6Q6YNh4fbFR+vgnRVpx1bPhjNSuCUC3hC9rTITx3ziRxTwkUV65H8aVi32q9sIfAtM4O5hfJB1d/xewC4GzDANuegZT1PG8IylKNa/+6umbuuN2LYfldveahMecwEbnkW8j/xCHtcqTqjzKrqd0VyY/LXst2BkYFgx9LblwwRQmHZyqogeiC6ldw44YODw2cQl0Pfesza0phrmAQmfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgA6Tkx3i7uRwtgPq2ZUqZstJggteHCJUReIjYFTtLE=; b=cIyaTgaBtXuzipNsJ8r93Y9Zw9A16g/X/nnv4RsZQcmgcqz3NEwKqc9Xff2zSJPU3lAB/2JmiyE0UEt5KESuJClRciFUT9nnxSdt3lcFNesAssLMae93r6yk/fgZ3VM0o2yFQJr6svl61Rs+0YBeC4/LcWNplcoASYXzmY+xmJLuJwSRqo1M6lxL5FEbLuPuII/7yyCYaxxT0xeHEDeWdRzz2SCt4zleVoTuHKtteG+dXSjv3tN8ZIEMZssjKxFUXB0su36fEOs8kb4orCRkXuKFhg91XEOJ+XAJ8bX7DlgAQNRonI6etilCBg8cTbPJuY+UYGyBNOZ6Vv3pvvWICw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgA6Tkx3i7uRwtgPq2ZUqZstJggteHCJUReIjYFTtLE=; b=SIz/k6d+6GkDcBXCU4KelxV+BB6nBUhg/OgbIdr0OI66gCWv5/PuwQB/It0X89c1njAfwlnutg0UHTVDkHCc/X93YsEYbAZ/9beeejOIxkzFQRACpruTkoyYSGnLfKXRsIeD7/z4OKcsBUdrDUXb0MTW3RlcEg+cPT1YkNVpa2Q=
Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0817.namprd00.prod.outlook.com (2603:10b6:208:1c8::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3032.0; Sun, 10 May 2020 20:23:57 +0000
Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073%7]) with mapi id 15.20.3031.000; Sun, 10 May 2020 20:23:57 +0000
From: Mike Jones 
To: Dick Hardt 
CC: Torsten Lodderstedt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYnCOz2ZWcGVYdMTY2lND/nBCHDyQ==
Date: Sun, 10 May 2020 20:23:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6f86ef27-4090-4484-888d-00009a3dd372; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-10T20:22:12Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 36e98abd-f334-432d-21d7-08d7f5201120
x-ms-traffictypediagnostic: BL0PR00MB0817:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 039975700A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jrgPrjJXCBdvJepFV428ErIG85AxMZMi153H4eFgiLHRizGwGbm/VHT2xUHD8GudBvMKsNnMvAkJ/2sSZBXn9UCR8Cturr2Z64sBAMxs4BEbaTLRWV4n+7sHLUFBFHEPV8OLyOaWTt30Mhbcf8FGHjPCxOJWgQfE5ufHSPI+hwEAwM5Vu/FCmZQULiEzX78j5sqBbzAf+KFASoa9rO27Wyd/aMdmP80Jp21KAtuF625OULTNgAD0vlWt2Y7atzT/8v4lXRae66F5AqEF7IayPo2UcRuEDa1KWK6Zqj/k1TxfRdfR++g6Bxv7oezNcFZ6C+MyU8Xv8uaI7F5o7UtadkI0AW6N45E3YgeqZES6rt4d4lcOOfJLrcScgMAcT31Kh9IRVHpgIBkbBbOm/9AFToRy824JIcPOAhPWw7CiKRC8KjApRVHq1z8Iai4HLrHqyKhmLHyCgjB/tW7x3cI+gNRPrKOjdkmhYwOBR99ilTWInbo/zgEf1upucA7c9N6HiWgBOrl7pCUGOXcMQ8KFmA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(346002)(376002)(39860400002)(366004)(396003)(33430700001)(76116006)(82950400001)(66946007)(64756008)(66556008)(66446008)(66476007)(316002)(53546011)(6506007)(966005)(2906002)(8676002)(86362001)(8936002)(9686003)(54906003)(6916009)(33656002)(55016002)(52536014)(7696005)(478600001)(5660300002)(71200400001)(8990500004)(33440700001)(82960400001)(4326008)(10290500003)(166002)(66574014)(186003)(26005)(76236002)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: GtVVRZ1EGA9CW2aaUyL46U+jGWSLB9jiGVltonwMs9LlWyOcvmV4RhlMsNVzbgsLl9njFxtlaJjRMo6PZwwvGb586y9CqsHI+Mi7nnhOEeKjve8CS14yS65HtjQ6mY8x+xfGsjNFEVIOcGLNXzLS5CbU0IH1CsVKTFutbrNRk8ogTciplKtJCbdAiQHlP7MHC0NxZSvnSWjHhJd1txmckNQGxCs/u5ypxiRw+07RSrxkBKIHUSV9zG54PM8DqRgU64FwWQdQozcfPKuBF6pv0XhG268j+hskUEpM+U0XKobRDqYWAvyH9Pxut5fLCihbvdBU52zkdW0FTOOZH65UlWulCz7DRnoOjtmiNHSyAWYnztJW9bROWP7NaFgh5v6ZU4lMJQ1ij1AMO58G9CGYmtcWHBvxWqH1Sfo9shNYjAbmluSY1+KN1ux6SMgfuVYa2Ttp+TXGNY2e24UAC+dc5OWC1DA1402mnRMxwbsOUK4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688A376C44B8236B7F50F30F5A00MN2PR00MB0688namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36e98abd-f334-432d-21d7-08d7f5201120
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 20:23:57.0445 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SzxgxZyyJ5NCyYQ//ImWlOhLMmPbY4OaLUPTQO1xB2Cs5Ia2KqqAAa9AvixKtvs8wvuQAb5tFtj47/p88mxuRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0817
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:24:06 -0000

--_000_MN2PR00MB0688A376C44B8236B7F50F30F5A00MN2PR00MB0688namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBPQXV0aCAyLjEgaXMgc3VwcG9zZWQgdG8gY29tcGF0aWJs
ZSB3aXRoIE9BdXRoIDIuMCAod2hpY2ggaXMgbXkgd2hvbGUgZ29hbCBoZXJlKSwgd2hlcmVhcyBP
QXV0aCAyLjAgd2FzIGluY29tcGF0aWJsZSB3aXRoIE9BdXRoIDEuMCBieSBkZXNpZ24uDQoNCkZy
b206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KU2VudDogU3VuZGF5LCBNYXkg
MTAsIDIwMjAgMTI6NTggUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb20+DQpDYzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+
OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVx
dWlyZSBQS0NFPw0KDQpKdXN0IGFzIHVwZ3JhZGluZyB0byBPQXV0aCAyLjAgZnJvbSBPQXV0aCAx
LjAgd2FzIHZvbHVudGFyeSwgd2h5IGlzIHVwZ3JhZGluZyB0byBPQXV0aCAyLjEgbm90IHZvbHVu
dGFyeT8NCg0KT0F1dGggMi4wIG9ic29sZXRlZCBPQXV0aCAxLjAsIGp1c3QgYXMgT0F1dGggMi4x
IGlzIG9ic29sZXRpbmcgT0F1dGggMi4xLiBPdXIgZ29hbCBpcyBmb3IgbmV3IGRlcGxveW1lbnRz
LCB0aGF0IGFyZSByZWFkaW5nIHRoZSBkcmFmdHMsIHRvIHVzZSB0aGUgYmVzdCBwcmFjdGljZXMu
DQoNCklmIGV4aXN0aW5nIGRlcGxveW1lbnRzIGRvbid0IHdhbnQgdGhlIGFkdmFudGFnZXMgb2Yg
YSBuZXcgdmVyc2lvbiBvciBleHRlbnNpb24sIHRoZXJlIGlzIG5vYm9keSBmb3JjaW5nIHRoZW0g
dG8gdXBncmFkZSAtLSBoZW5jZSBteSBjb25mdXNpb24gb24geW91ciBzdGF0ZW1lbnQgdGhhdCBp
dCBpcyAibWFuZGF0b3J5Ii4gVXBncmFkaW5nIHRvIE9BdXRoIDIuMCBmcm9tIE9BdXRoIDEuMCB3
YXMgbm90IG1hbmRhdG9yeSwgYW5kIHNvbWUgZGVwbG95bWVudHMgc3RpbGwgdXNlIE9BdXRoIDEu
MCB0b2RheS4NCg0KDQoNCuGQpw0KDQpPbiBTdW4sIE1heSAxMCwgMjAyMCBhdCAxMjo1MSBQTSBN
aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSWYgSeKAmW0gbm90IG1pc3Rha2VuLCB0aGUgT0F1
dGggMi4xIGRyYWZ0IGlzIGludGVuZGVkIHRvIG1ha2UgT0F1dGggMi4wIChSRkMgNjc0OSkgb2Jz
b2xldGUsIGp1c3QgbGlrZSBPQXV0aCAyLjAgKFJGQyA2NzQ5KSBtYWRlIE9BdXRoIDEuMCAoUkZD
IDU4NDkpIG9ic29sZXRlLiAgVGhhdOKAmXMgd2hhdCBtYWtlcyBtZSB0aGluayBkZXZlbG9wZXJz
IHdvdWxkIHZpZXcgdXBkYXRpbmcgYXMgbWFuZGF0b3J5LiAgSWYgeW914oCZcmUgd2lsbGluZyB0
byByZW1vdmUgdGhlIOKAnHJlcGxhY2VzIDY3NDnigJ0gY2xhdXNlIGZyb20gdGhlIGRyYWZ0LCB0
aGVuIHRoZXJlIHdvdWxkIGJlIG5vIHBlcmNlcHRpb24gcHJvYmxlbSwgYXMgaXQgd291bGQgYmUg
Y2xlYXIgdGhhdCBhZG9wdGlvbiBvZiAyLjEgd291bGQgYmUgdm9sdW50YXJ5LCBqdXN0IGxpa2Ug
dGhlIG90aGVyIGV4dGVuc2lvbiBzcGVjcy4NCg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJk
dEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NClNlbnQ6IFN1bmRheSwg
TWF5IDEwLCAyMDIwIDEyOjM4IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFRvcnN0
ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxv
ZGRlcnN0ZWR0Lm5ldD4+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpT
dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/DQoNCkhpIE1p
a2UsIEkgd291bGQgY29uc2lkZXIgdXBncmFkaW5nIHRvIE9BdXRoIDIuMSB0byBiZSB2b2x1bnRh
cnksIGp1c3QgYXMgdGhlIG90aGVyIGV4dGVuc2lvbnMuIFNpbWlsYXJseSwgT0F1dGggMS4wIGRl
cGxveW1lbnRzIHVwZ3JhZGluZyB0byBPQXV0aCAyLjAgd2FzIHZvbHVudGFyeS4NCg0KV291bGQg
eW91IGNsYXJpZnkgd2h5IHlvdSB0aGluayB1cGdyYWRpbmcgdG8gT0F1dGggMi4xIHdvdWxkIGJl
IG1hbmRhdG9yeT8NCg0KDQpPbiBTdW4sIE1heSAxMCwgMjAyMCBhdCAxMjowMiBQTSBNaWtlIEpv
bmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86
NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJIGFncmVlIHdpdGggYWN0
aXZlbHkgbWFpbnRhaW5pbmcgYW5kIGltcHJvdmluZyB0aGUgT0F1dGggMi4wIHNwZWNzIGJ5IGFk
ZGluZyBlbmhhbmNlbWVudHMgdGhhdCBhcmUgdm9sdW50YXJ5IHRvIHVzZS4gIEnigJl2ZSB3b3Jr
ZWQgb24gbWFueSBzdWNoIGltcHJvdmVtZW50cywgaW5jbHVkaW5nIER5bmFtaWMgQ2xpZW50IFJl
Z2lzdHJhdGlvbiwgQXV0aG9yaXphdGlvbiBNZXRhZGF0YSwgdGhlIERldmljZSBGbG93LCBUb2tl
biBFeGNoYW5nZSwgRFBvUCwgYW5kIHN1cHBvcnQgUEFSIGFuZCBSQVIsIGV0Yy4gIFRoZSBpc3N1
ZSB0aGF04oCZcyB0aGUgc3ViamVjdCBpcyB0aGUgY3VycmVudCBkaXNjdXNzaW9uIGlzIHdoZXRo
ZXIgdG8gbWFrZSB1c2Ugb2YgYW5vdGhlciBlbmhhbmNlbWVudCwgUEtDRSwgbWFuZGF0b3J5IGlu
IGNhc2VzIHdoZXJlIGl04oCZcyBhY3R1YWxseSBub3QgbmVlZGVkLCByYXRoZXIgdGhhbiBtYWtp
bmcgaXRzIHVzZSB2b2x1bnRhcnkgbGlrZSB0aGUgb3RoZXIgZW5oYW5jZW1lbnRzLCB3aGljaCBJ
IGNlcnRhaW5seSBzdXBwb3J0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0
IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGxvZGRl
cnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+DQpTZW50OiBTdW5kYXksIE1heSAxMCwgMjAyMCAz
OjE1IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0
bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IERhbmllbCBGZXR0IDxmZXR0QGRh
bmllbGZldHQuZGU8bWFpbHRvOmZldHRAZGFuaWVsZmV0dC5kZT4+OyBvYXV0aEBpZXRmLm9yZzxt
YWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbT0FVVEgtV0dd
IE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KSGkgTWlrZSwNCg0KTWlrZSBKb25lcyA8TWlj
aGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9z
b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHNjaHJpZWIgYW0gRnIuIDguIE1haSAyMDIwIHVtIDE4
OjU1Og0KT0F1dGggMi4xIHdhcyBzdXBwb3NlZCB0byBub3QgaW50cm9kdWNlIGJyZWFraW5nIGNo
YW5nZXMuDQpJIGNhbm5vdCByZW1lbWJlciB0aGUgV0cgbWV0IHRoYXQgZGVjaXNpb24uIENhbiB5
b3UgcGxlYXNlIHJlZmVyIHRvIHRoZSByZXNwZWN0aXZlIHRocmVhZD8NCg0KUmVxdWlyaW5nIGV4
YWN0IHJlZGlyZWN0IFVSSSBtYXRjaGluZyBpcyBhbHJlYWR5IGEgYnJlYWtpbmcgY2hhbmdlLiBE
byB5b3Ugb3Bwb3NlIGFnYWluc3QgdGhpcyBhcyB3ZWxsPw0KDQoNCklmIHlvdSB3YW50IHRvIGRv
IHRoYXQsIHBsZWFzZSBkbyBpdCBpbiBUeEF1dGggaW5zdGVhZC4NCg0KSW50ZXJlc3Rpbmcgc3Rh
dGVtZW50LiBEb2VzIGl0IG1lYW4geW91IHdhbnQgdG8gY29uc2VydmUgT0F1dGggMi4wIGFuZCBm
b3JjZSBhbnkgZW5oYW5jZW1lbnRzL2ltcHJvdmVtZW50cyB0byBnbyBpbnRvIFRYQXV0aD8gVGhp
cyB3b3VsZCBjYXVzZSBodWdlIG1pZ3JhdGlvbiBlZmZvcnRzIGZvciBleGlzdGluZyBkZXBsb3lt
ZW50cyB3YW50aW5nIHRvIGJlbmVmaXQgZnJvbSB0aG9zZSBlbmhhbmNlbWVudHMuDQoNCkkgdGhp
bmsgZXhpc3RpbmcgZGVwbG95bWVudHMgYXJlIGJldHRlciBzZXJ2ZWQgYnkgYWN0aXZlbHkgbWFp
bnRhaW5pbmcgYW5kIGV2b2x2aW5nIHRoZSAyLnggbGluZS4gRm9yIGV4YW1wbGUsIFBBUiBhbmQg
UkFSIGFyZSBhdHRlbXB0cyB0byBpbXByb3ZlIE9BdXRoIDIueCBhbmQgbWFrZSBpdCB1c2FibGUg
Zm9yIG5ldyB1c2UgY2FzZXMuIFRoYXTigJlzIGJldHRlciBwcm90ZWN0aW9uIG9mIGV4aXN0aW5n
IGludmVzdG1lbnRzIHRoYW4gc2VuZGluZyB0aGVtIG9mIHRvIFRYQXV0aC4NCktpbmQgcmVnYXJk
cywNClRvcnN0ZW4uDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRGFuaWVs
IEZldHQNClNlbnQ6IFRodXJzZGF5LCBNYXkgNywgMjAyMCAxMTo1MCBQTQ0KVG86IG9hdXRoQGll
dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9B
dXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KKzEgdG8gYWxsIHdoYXQgQWFyb24gc2FpZC4gVGhh
bmtzIGZvciBwb2ludGluZyB0aGlzIG91dCENCg0KV2UgbmVlZCB0byBhZGRyZXNzIHRoaXMgaW4g
dGhlIHNlY3VyaXR5IEJDUCBhbmQgdGhpcyB3aWxsIGJlIGEgbm9ybWF0aXZlIGNoYW5nZSB0aGF0
IGFmZmVjdHMgT3BlbklEIENvbm5lY3QgQ29yZSAoanVzdCBhcyBvdXIgY3VycmVudCByZWNvbW1l
bmRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2Ygbm9uY2UpLg0KDQpXZSB3b3VsZCB0aGVuIGhhdmU6DQoN
Ci0gdXNlIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgdXNlIE9JREMgd2l0aCBhIG5vbmNlLCB0aGVuIHlv
dSBkb24ndCBuZWVkIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgYXJlIGEgcHVibGljIGNsaWVudCwgdGhl
biB5b3Ugc3RpbGwgbmVlZCBQS0NFLg0KLSB1c2Ugc3RhdGUsIGV4Y2VwdCBpZiB5b3UgdXNlIFBL
Q0UsIHRoZW4geW91IGRvbid0IG5lZWQgc3RhdGUuDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHZlcnkg
Z29vZCByZWFzb25zIHRvIHNpbXBsaWZ5IHRoaXMgZG93biB0bw0KDQotIHVzZSBQS0NFDQotIHlv
dSBtYXkgb3IgbWF5IG5vdCB1c2Ugc3RhdGUNCg0KRmlyc3QgYW5kIGZvcmVtb3N0LCBub3QgbWFu
eSBwZW9wbGUgd2lsbCB1bmRlcnN0YW5kIHdoeSB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUgQkNQ
L09BdXRoIDIuMSBtYW5kYXRlIFBLQ0UgYW5kIHNvbWUgd2hlcmUgdGhleSBkb24ndC4gSG93ZXZl
ciwgdW5kZXJzdGFuZGluZyB3aHkgeW91IGhhdmUgdG8gZG8gc29tZXRoaW5nIGlzIGtleSB0byBj
b21wbGlhbmNlLiBUaGUgc2hvcnQgdmVyc2lvbiAiUEtDRSBwcm90ZWN0cyB0aGUgY29kZTsgdGhl
cmUgaXMgYSBzcGVjaWZpYyBjYXNlIHdoZXJlIGl0IGlzIG5vdCBuZWVkZWQsIGJ1dCBpdHMgYmV0
dGVyIHRvIHVzZSBpdCBhbGwgdGhlIHRpbWUiIGlzIGVhc3kgdG8gdW5kZXJzdGFuZC4gV2Ugd2ls
bCBub3Qgc2VlIG1hbnkgaW1wbGVtZW50YXRpb25zIGZvbGxvd2luZyB0aGUgbG9uZyB2ZXJzaW9u
IGFib3ZlIGNvcnJlY3RseS4NCg0KU2Vjb25kLCB3ZSBkcmFtYXRpY2FsbHkgcmVkdWNlIHRlY2hu
aWNhbCBjb21wbGV4aXR5IGJ5IHJlZHVjaW5nIGNhc2VzIHRoYXQgbmVlZCB0byBiZSBoYW5kbGVk
LiBXZSByZWR1Y2UgY29ycmVjdG5lc3MgYW5kIGNvbXBsaWFuY2UgdGVzdGluZyBjb21wbGV4aXR5
IGluIHRoZSBzYW1lIHdheS4gV2UgcmVkdWNlIHRoZSBjb3N0IG9mIHNlY3VyaXR5IGFuYWx5c2lz
LCB3aGljaCBzY2FsZXMgcmVhbGx5IGJhZGx5IHRvIG1vcmUgY2FzZXMuDQoNCkFuZCBmaW5hbGx5
LCB1c2luZyBub25jZSB0byBwcm90ZWN0IGFnYWluc3QgY29kZSBpbmplY3Rpb24gaXMgbGVzcyBy
b2J1c3QgdGhhbiBQS0NFLiBBUyBoYXZlIGEgYmV0dGVyIHRyYWNrIHJlY29yZCB0aGFuIGNsaWVu
dHMgd2hlbiBpdCBjb21lcyB0byBjb3JyZWN0bHkgaW1wbGVtZW50aW5nIHNlY3VyaXR5IG1lY2hh
bmlzbXMuDQoNClllcywgdGhpcyB3aWxsIG1ha2UgYSBudW1iZXIgb2YgaW1wbGVtZW50YXRpb25z
IG5vbi1zcGVjLWNvbXBsaWFudCwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBhIGh1
Z2UgcHJvYmxlbS4gU29mdHdhcmUgbmVlZHMgdG8gYWRhcHQgYWxsIHRoZSB0aW1lIGFuZCBhIHNv
ZnR3YXJlIHRoYXQgaGFzIG5vdCBiZWVuIGNoYW5nZWQgaW4gYSB3aGlsZSBpcyBwcm9iYWJseSBu
b3Qgb25lIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhbnl3YXkuIFdlIGFyZSBzZXR0aW5nIGEgbmV3
IGdvYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byBtZWV0IGFuZCBldmVudHVhbGx5LCBtYWludGFp
bmVkIGltcGxlbWVudGF0aW9ucyB3aWxsIGdldCB0aGVyZS4NCg0KLURhbmllbA0KDQoNCkFtIDA4
LjA1LjIwIHVtIDAxOjM4IHNjaHJpZWIgQWFyb24gUGFyZWNraToNCkJhY2tpbmcgdXAgYSBzdGVw
IG9yIHR3bywgdGhlcmUncyBhbm90aGVyIHBvaW50IGhlcmUgdGhhdCBJIHRoaW5rIGhhcyBiZWVu
IG1pc3NlZCBpbiB0aGVzZSBkaXNjdXNzaW9ucy4NCg0KUEtDRSBzb2x2ZXMgdHdvIHByb2JsZW1z
OiBzdG9sZW4gYXV0aG9yaXphdGlvbiBjb2RlcyBmb3IgcHVibGljIGNsaWVudHMsIGFuZCBhdXRo
b3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGZvciBhbGwgY2xpZW50cy4gV2UndmUgb25seSBiZWVu
IHRhbGtpbmcgYWJvdXQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBvbiB0aGUgbGlzdCBz
byBmYXIuIFRoZSBxdW90ZWQgc2VjdGlvbiBvZiB0aGUgc2VjdXJpdHkgQkNQICg0LjUuMykgd2hp
Y2ggc2F5cyBjbGllbnRzIGNhbiBkbyBQS0NFIG9yIHVzZSB0aGUgbm9uY2UsIGlzIG9ubHkgdGFs
a2luZyBhYm91dCBwcmV2ZW50aW5nIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uDQoNClRo
ZSBub25jZSBwYXJhbWV0ZXIgc29sdmVzIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gaWYg
dGhlIGNsaWVudCByZXF1ZXN0cyBhbiBJRCB0b2tlbi4gUHVibGljIGNsaWVudHMgdXNpbmcgdGhl
IG5vbmNlIHBhcmFtZXRlciBhcmUgc3RpbGwgc3VzY2VwdGlibGUgdG8gc3RvbGVuIGF1dGhvcml6
YXRpb24gY29kZXMgc28gdGhleSBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgYXMgd2VsbC4NCg0KVGhl
IG9ubHkgY2FzZSB3aGVyZSBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIGRvbid0IGJlbmVmaXQgZnJv
bSBQS0NFIGlzIGlmIHRoZXkgYXJlIGFsc28gY29uZmlkZW50aWFsIGNsaWVudHMuIFB1YmxpYyBj
bGllbnQgT0lEQyBjbGllbnRzIHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBldmVuIGlmIHRoZXkgY2hl
Y2sgdGhlIG5vbmNlLg0KDQpPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIHdvcmtpbmcgd2l0aCBjb25m
aWRlbnRpYWwgY2xpZW50cyBzdGlsbCBiZW5lZml0IGZyb20gUEtDRSBiZWNhdXNlIHRoZXkgY2Fu
IHRoZW4gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBwcm90ZWN0aW9u
IHNlcnZlci1zaWRlIHJhdGhlciB0aGFuIGNyb3NzIHRoZWlyIGZpbmdlcnMgdGhhdCBjbGllbnRz
IGltcGxlbWVudGVkIHRoZSBub25jZSBjaGVjayBwcm9wZXJseS4NCg0KSSByZWFsbHkgZG9uJ3Qg
dGhpbmsgaXQncyB3b3J0aCB0aGUgYW1vdW50IG9mIGV4cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtl
IGluIHRoZSBmdXR1cmUgdG8gd3JpdGUgYW4gZXhjZXB0aW9uIGludG8gT0F1dGggMi4xIG9yIHRo
ZSBTZWN1cml0eSBCQ1AgZm9yIG9ubHkgc29tZSB0eXBlcyBvZiBPcGVuSUQgQ29ubmVjdCBjbGll
bnRzIHdoZW4gYWxsIGNsaWVudHMgd291bGQgYmVuZWZpdCBmcm9tIFBLQ0UgYW55d2F5Lg0KDQpB
YXJvbg0KDQoNCg0KT24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMDo0OCBBTSBEaWNrIEhhcmR0IDxk
aWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToN
CkhlbGxvIQ0KDQpXZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGgg
Mi4xIGNvZGUgZmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBp
cyBub3QgY29tbW9uIGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZl
cyBzb21lIG9mIHRoZSBpc3N1ZXMgdGhhdCBQS0NFIHByb3RlY3RzIGFnYWluc3QuIFdlIHRoaW5r
IHRoYXQgbW9zdCBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBzdXBwb3J0IE9B
dXRoIDIuMCwgYW5kIGhlbmNlIGhhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVz
dCBwcmFjdGljZXMuDQoNClRoZSBhZHZhbnRhZ2VzIG9yIHJlcXVpcmluZyBQS0NFIGFyZToNCg0K
LSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlv
bnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NFDQoNCi0gcmVkdWNlZCBhdHRhY2sg
c3VyZmFjZSB3aGVuIHVzaW5nICBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlmaWVy
IGlzIHNlbnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZh
bHVlDQoNCi0gZW5mb3JjZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0
byBoYW5kbGUgZm9yIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVj
ayBpcyBjb25kdWN0ZWQNCg0KV2hhdCBhcmUgZGlzYWR2YW50YWdlcyBiZXNpZGVzIHRoZSBwb3Rl
bnRpYWwgaW1wYWN0IHRvIE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlmaWNh
bnQgaXMgdGhhdCBpbXBhY3Q/DQoNCkRpY2ssIEFhcm9uLCBhbmQgVG9yc3Rlbg0KDQrhkKcNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0
aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg
bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aA0K4ZCnDQo=

--_000_MN2PR00MB0688A376C44B8236B7F50F30F5A00MN2PR00MB0688namp_
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
bWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz
O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K
PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91
dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlIGRp
ZmZlcmVuY2UgaXMgdGhhdCBPQXV0aCAyLjEgaXMgc3VwcG9zZWQgdG8gY29tcGF0aWJsZSB3aXRo
IE9BdXRoIDIuMCAod2hpY2ggaXMgbXkgd2hvbGUgZ29hbCBoZXJlKSwgd2hlcmVhcyBPQXV0aCAy
LjAgd2FzIGluY29tcGF0aWJsZSB3aXRoIE9BdXRoIDEuMCBieSBkZXNpZ24uPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw
NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBEaWNrIEhhcmR0ICZsdDtkaWNr
LmhhcmR0QGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDEwLCAy
MDIwIDEyOjU4IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZs
dDt0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDs7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT88bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBhcyB1cGdyYWRpbmcgdG8gT0F1
dGggMi4wIGZyb20gT0F1dGggMS4wIHdhcyB2b2x1bnRhcnksIHdoeSBpcyB1cGdyYWRpbmcgdG8g
T0F1dGggMi4xIG5vdCB2b2x1bnRhcnk/Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PQXV0aCAyLjAgb2Jzb2xldGVkIE9BdXRoIDEuMCwganVzdCBh
cyBPQXV0aCAyLjEgaXMgb2Jzb2xldGluZyBPQXV0aCAyLjEuIE91ciBnb2FsIGlzIGZvciBuZXcg
ZGVwbG95bWVudHMsIHRoYXQgYXJlIHJlYWRpbmcgdGhlIGRyYWZ0cywgdG8gdXNlIHRoZSBiZXN0
IHByYWN0aWNlcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PklmIGV4aXN0aW5nIGRlcGxveW1lbnRzIGRvbid0IHdhbnQgdGhlIGFkdmFudGFnZXMgb2YgYSBu
ZXcgdmVyc2lvbiBvciBleHRlbnNpb24sIHRoZXJlIGlzIG5vYm9keSBmb3JjaW5nIHRoZW0gdG8g
dXBncmFkZSAtLSBoZW5jZSBteSBjb25mdXNpb24gb24geW91ciBzdGF0ZW1lbnQgdGhhdCBpdCBp
cyAmcXVvdDttYW5kYXRvcnkmcXVvdDsuIFVwZ3JhZGluZyB0byBPQXV0aCAyLjAgZnJvbSBPQXV0
aCAxLjAgd2FzIG5vdCBtYW5kYXRvcnksDQogYW5kIHNvbWUgZGVwbG95bWVudHMgc3RpbGwgdXNl
IE9BdXRoIDEuMCB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aW1nIHdpZHRoPSIxIiBoZWlnaHQ9
IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hlaWdodDouMDEwNGluIiBpZD0iX3gwMDAwX2kxMDI3
IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9Z
WEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTQxZDIw
YWUwLTNlYmQtNDc3ZC04ZWQ2LTAyYWZmOWU2NWI5NyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3
LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0
ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gU3VuLCBNYXkgMTAsIDIwMjAgYXQgMTI6NTEgUE0gTWlrZSBKb25lcyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp
biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPklmIEnigJltIG5vdCBtaXN0YWtlbiwgdGhlIE9BdXRoIDIuMSBkcmFmdCBp
cyBpbnRlbmRlZCB0byBtYWtlIE9BdXRoIDIuMCAoUkZDIDY3NDkpIG9ic29sZXRlLCBqdXN0IGxp
a2UgT0F1dGggMi4wIChSRkMgNjc0OSkgbWFkZSBPQXV0aCAxLjAgKFJGQyA1ODQ5KQ0KIG9ic29s
ZXRlLiZuYnNwOyBUaGF04oCZcyB3aGF0IG1ha2VzIG1lIHRoaW5rIGRldmVsb3BlcnMgd291bGQg
dmlldyB1cGRhdGluZyBhcyBtYW5kYXRvcnkuJm5ic3A7IElmIHlvdeKAmXJlIHdpbGxpbmcgdG8g
cmVtb3ZlIHRoZSDigJxyZXBsYWNlcyA2NzQ54oCdIGNsYXVzZSBmcm9tIHRoZSBkcmFmdCwgdGhl
biB0aGVyZSB3b3VsZCBiZSBubyBwZXJjZXB0aW9uIHByb2JsZW0sIGFzIGl0IHdvdWxkIGJlIGNs
ZWFyIHRoYXQgYWRvcHRpb24gb2YgMi4xIHdvdWxkIGJlIHZvbHVudGFyeSwNCiBqdXN0IGxpa2Ug
dGhlIG90aGVyIGV4dGVuc2lvbiBzcGVjcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxiPkZyb206PC9iPiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGlj
ay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwv
YT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXkgMTAsIDIwMjAgMTI6MzggUE08
YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9y
c3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgTWlrZSwgSSB3b3VsZCBj
b25zaWRlciB1cGdyYWRpbmcgdG8gT0F1dGggMi4xIHRvIGJlIHZvbHVudGFyeSwganVzdCBhcyB0
aGUgb3RoZXIgZXh0ZW5zaW9ucy4gU2ltaWxhcmx5LCBPQXV0aCAxLjAgZGVwbG95bWVudHMgdXBn
cmFkaW5nIHRvIE9BdXRoIDIuMCB3YXMgdm9sdW50YXJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldvdWxkIHlvdSBjbGFyaWZ5IHdoeSB5
b3UgdGhpbmsgdXBncmFkaW5nJm5ic3A7dG8gT0F1dGggMi4xIHdvdWxkIGJlIG1hbmRhdG9yeT88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5PbiBTdW4sIE1heSAxMCwgMjAyMCBhdCAxMjowMiBQTSBNaWtlIEpvbmVzICZsdDtNaWNo
YWVsLkpvbmVzPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgYWdyZWUgd2l0aCBhY3RpdmVseSBtYWlu
dGFpbmluZyBhbmQgaW1wcm92aW5nIHRoZSBPQXV0aCAyLjAgc3BlY3MgYnkgYWRkaW5nIGVuaGFu
Y2VtZW50cyB0aGF0IGFyZSB2b2x1bnRhcnkgdG8gdXNlLiZuYnNwOyBJ4oCZdmUgd29ya2VkIG9u
IG1hbnkgc3VjaCBpbXByb3ZlbWVudHMsDQogaW5jbHVkaW5nIER5bmFtaWMgQ2xpZW50IFJlZ2lz
dHJhdGlvbiwgQXV0aG9yaXphdGlvbiBNZXRhZGF0YSwgdGhlIERldmljZSBGbG93LCBUb2tlbiBF
eGNoYW5nZSwgRFBvUCwgYW5kIHN1cHBvcnQgUEFSIGFuZCBSQVIsIGV0Yy4mbmJzcDsgVGhlIGlz
c3VlIHRoYXTigJlzIHRoZSBzdWJqZWN0IGlzIHRoZSBjdXJyZW50IGRpc2N1c3Npb24gaXMgd2hl
dGhlciB0byBtYWtlIHVzZSBvZiBhbm90aGVyIGVuaGFuY2VtZW50LCBQS0NFLCBtYW5kYXRvcnkg
aW4gY2FzZXMNCiB3aGVyZSBpdOKAmXMgYWN0dWFsbHkgbm90IG5lZWRlZCwgcmF0aGVyIHRoYW4g
bWFraW5nIGl0cyB1c2Ugdm9sdW50YXJ5IGxpa2UgdGhlIG90aGVyIGVuaGFuY2VtZW50cywgd2hp
Y2ggSSBjZXJ0YWlubHkgc3VwcG9ydC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFRvcnN0
ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49PGEgaHJlZj0ibWFpbHRvOjQwbG9kZGVyc3RlZHQu
bmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBsb2RkZXJzdGVkdC5uZXRAZG1h
cmMuaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDEwLCAy
MDIwIDM6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0
bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRGFuaWVsIEZldHQgJmx0
OzxhIGhyZWY9Im1haWx0bzpmZXR0QGRhbmllbGZldHQuZGUiIHRhcmdldD0iX2JsYW5rIj5mZXR0
QGRhbmllbGZldHQuZGU8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBb
RVhURVJOQUxdIFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT88bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBNaWtlLDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPk1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9z
b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBk
bWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHNjaHJpZWIgYW0gRnIuIDguIE1haSAyMDIwIHVtIDE4OjU1
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+T0F1dGggMi4xIHdhcyBzdXBwb3Nl
ZCB0byBub3QgaW50cm9kdWNlIGJyZWFraW5nIGNoYW5nZXMuJm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkkgY2Fubm90IHJlbWVtYmVyIHRoZSBXRyBtZXQgdGhhdCBkZWNpc2lvbi4g
Q2FuIHlvdSBwbGVhc2UgcmVmZXIgdG8gdGhlIHJlc3BlY3RpdmUgdGhyZWFkPyZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVx
dWlyaW5nIGV4YWN0IHJlZGlyZWN0IFVSSSBtYXRjaGluZyBpcyBhbHJlYWR5IGEgYnJlYWtpbmcg
Y2hhbmdlLiBEbyB5b3Ugb3Bwb3NlIGFnYWluc3QgdGhpcyBhcyB3ZWxsPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JZiB5b3Ugd2FudCB0byBkbyB0aGF0LCBwbGVh
c2UgZG8gaXQgaW4gVHhBdXRoIGluc3RlYWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5JbnRlcmVzdGluZyBzdGF0ZW1lbnQuIERvZXMgaXQgbWVhbiB5b3Ugd2FudCB0byBjb25zZXJ2
ZSBPQXV0aCAyLjAgYW5kIGZvcmNlIGFueSBlbmhhbmNlbWVudHMvaW1wcm92ZW1lbnRzIHRvIGdv
IGludG8gVFhBdXRoPyBUaGlzIHdvdWxkIGNhdXNlIGh1Z2UgbWlncmF0aW9uIGVmZm9ydHMgZm9y
IGV4aXN0aW5nDQogZGVwbG95bWVudHMgd2FudGluZyB0byBiZW5lZml0IGZyb20gdGhvc2UgZW5o
YW5jZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SSB0aGluayBleGlzdGluZyBkZXBsb3ltZW50cyBhcmUgYmV0dGVyIHNlcnZl
ZCBieSBhY3RpdmVseSBtYWludGFpbmluZyBhbmQgZXZvbHZpbmcgdGhlIDIueCBsaW5lLiBGb3Ig
ZXhhbXBsZSwgUEFSIGFuZCBSQVIgYXJlIGF0dGVtcHRzIHRvIGltcHJvdmUgT0F1dGggMi54IGFu
ZCBtYWtlIGl0IHVzYWJsZSBmb3INCiBuZXcgdXNlIGNhc2VzLiBUaGF04oCZcyBiZXR0ZXIgcHJv
dGVjdGlvbiBvZiBleGlzdGluZyBpbnZlc3RtZW50cyB0aGFuIHNlbmRpbmcgdGhlbSBvZiB0byBU
WEF1dGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+VG9yc3Rlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy
MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9h
PiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGFuaWVsIEZldHQ8YnI+DQo8Yj5TZW50OjwvYj4g
VGh1cnNkYXksIE1heSA3LCAyMDIwIDExOjUwIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJt
YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQ
S0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
IzQzOzEgdG8gYWxsIHdoYXQgQWFyb24gc2FpZC4gVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91
dCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPldlIG5lZWQgdG8gYWRkcmVzcyB0aGlzIGluIHRoZSBzZWN1cml0eSBCQ1AgYW5kIHRoaXMg
d2lsbCBiZSBhIG5vcm1hdGl2ZSBjaGFuZ2UgdGhhdCBhZmZlY3RzIE9wZW5JRCBDb25uZWN0IENv
cmUgKGp1c3QgYXMgb3VyIGN1cnJlbnQgcmVjb21tZW5kYXRpb24gb24gdGhlIHVzYWdlIG9mIG5v
bmNlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPldlIHdvdWxkIHRoZW4gaGF2ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gdXNlIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgdXNl
IE9JREMgd2l0aCBhIG5vbmNlLCB0aGVuIHlvdSBkb24ndCBuZWVkIFBLQ0UsIGV4Y2VwdCBpZiB5
b3UgYXJlIGEgcHVibGljIGNsaWVudCwgdGhlbiB5b3Ugc3RpbGwgbmVlZCBQS0NFLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHVzZSBzdGF0
ZSwgZXhjZXB0IGlmIHlvdSB1c2UgUEtDRSwgdGhlbiB5b3UgZG9uJ3QgbmVlZCBzdGF0ZS48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg
dGhpbmsgdGhlcmUgYXJlIHZlcnkgZ29vZCByZWFzb25zIHRvIHNpbXBsaWZ5IHRoaXMgZG93biB0
bw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4tIHVzZSBQS0NFPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPi0geW91IG1heSBvciBtYXkgbm90IHVzZSBzdGF0ZTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rmlyc3QgYW5kIGZv
cmVtb3N0LCBub3QgbWFueSBwZW9wbGUgd2lsbCB1bmRlcnN0YW5kIHdoeSB0aGVyZSBhcmUgY2Fz
ZXMgd2hlbiB0aGUgQkNQL09BdXRoIDIuMSBtYW5kYXRlIFBLQ0UgYW5kIHNvbWUgd2hlcmUgdGhl
eSBkb24ndC4gSG93ZXZlciwgdW5kZXJzdGFuZGluZw0KPGk+d2h5PC9pPiB5b3UgaGF2ZSB0byBk
byBzb21ldGhpbmcgaXMga2V5IHRvIGNvbXBsaWFuY2UuIFRoZSBzaG9ydCB2ZXJzaW9uICZxdW90
O1BLQ0UgcHJvdGVjdHMgdGhlIGNvZGU7IHRoZXJlIGlzIGEgc3BlY2lmaWMgY2FzZSB3aGVyZSBp
dCBpcyBub3QgbmVlZGVkLCBidXQgaXRzIGJldHRlciB0byB1c2UgaXQgYWxsIHRoZSB0aW1lJnF1
b3Q7IGlzIGVhc3kgdG8gdW5kZXJzdGFuZC4gV2Ugd2lsbCBub3Qgc2VlIG1hbnkgaW1wbGVtZW50
YXRpb25zIGZvbGxvd2luZw0KIHRoZSBsb25nIHZlcnNpb24gYWJvdmUgY29ycmVjdGx5LjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2Vj
b25kLCB3ZSBkcmFtYXRpY2FsbHkgcmVkdWNlIHRlY2huaWNhbCBjb21wbGV4aXR5IGJ5IHJlZHVj
aW5nIGNhc2VzIHRoYXQgbmVlZCB0byBiZSBoYW5kbGVkLiBXZSByZWR1Y2UgY29ycmVjdG5lc3Mg
YW5kIGNvbXBsaWFuY2UgdGVzdGluZyBjb21wbGV4aXR5IGluIHRoZSBzYW1lIHdheS4gV2UgcmVk
dWNlDQogdGhlIGNvc3Qgb2Ygc2VjdXJpdHkgYW5hbHlzaXMsIHdoaWNoIHNjYWxlcyByZWFsbHkg
YmFkbHkgdG8gbW9yZSBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBmaW5hbGx5LCB1c2luZyBub25jZSB0byBwcm90ZWN0
IGFnYWluc3QgY29kZSBpbmplY3Rpb24gaXMgbGVzcyByb2J1c3QgdGhhbiBQS0NFLiBBUyBoYXZl
IGEgYmV0dGVyIHRyYWNrIHJlY29yZCB0aGFuIGNsaWVudHMgd2hlbiBpdCBjb21lcyB0byBjb3Jy
ZWN0bHkgaW1wbGVtZW50aW5nIHNlY3VyaXR5DQogbWVjaGFuaXNtcy4gPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIHRoaXMgd2ls
bCBtYWtlIGEgbnVtYmVyIG9mIGltcGxlbWVudGF0aW9ucyBub24tc3BlYy1jb21wbGlhbnQsIGJ1
dCBJIGRvIG5vdCB0aGluayB0aGF0IHRoaXMgaXMgYSBodWdlIHByb2JsZW0uIFNvZnR3YXJlIG5l
ZWRzIHRvIGFkYXB0IGFsbCB0aGUgdGltZSBhbmQgYSBzb2Z0d2FyZSB0aGF0IGhhcw0KIG5vdCBi
ZWVuIGNoYW5nZWQgaW4gYSB3aGlsZSBpcyBwcm9iYWJseSBub3Qgb25lIHlvdSB3b3VsZCB3YW50
IHRvIHVzZSBhbnl3YXkuIFdlIGFyZSBzZXR0aW5nIGEgbmV3IGdvYWwgZm9yIGltcGxlbWVudGF0
aW9ucyB0byBtZWV0IGFuZCBldmVudHVhbGx5LCBtYWludGFpbmVkIGltcGxlbWVudGF0aW9ucyB3
aWxsIGdldCB0aGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPi1EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbSAwOC4wNS4yMCB1bSAwMTozOCBzY2hyaWVi
IEFhcm9uIFBhcmVja2k6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUncyBh
bm90aGVyIHBvaW50IGhlcmUgdGhhdCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVzZSBk
aXNjdXNzaW9ucy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPlBLQ0Ugc29sdmVzIHR3byBwcm9ibGVtczogc3RvbGVuIGF1dGhvcml6YXRpb24gY29k
ZXMgZm9yIHB1YmxpYyBjbGllbnRzLCBhbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBm
b3IgYWxsIGNsaWVudHMuIFdlJ3ZlIG9ubHkgYmVlbiB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRp
b24gY29kZSBpbmplY3Rpb24NCiBvbiB0aGUgbGlzdCBzbyBmYXIuIFRoZSBxdW90ZWQgc2VjdGlv
biBvZiB0aGUgc2VjdXJpdHkgQkNQICg0LjUuMykgd2hpY2ggc2F5cyBjbGllbnRzIGNhbiBkbyBQ
S0NFIG9yIHVzZSB0aGUgbm9uY2UsIGlzIG9ubHkgdGFsa2luZyBhYm91dCBwcmV2ZW50aW5nIGF1
dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgbm9uY2UgcGFyYW1ldGVyIHNvbHZlcyBh
dXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gSUQg
dG9rZW4uIFB1YmxpYyBjbGllbnRzIHVzaW5nIHRoZSBub25jZSBwYXJhbWV0ZXIgYXJlIHN0aWxs
IHN1c2NlcHRpYmxlIHRvIHN0b2xlbiBhdXRob3JpemF0aW9uDQogY29kZXMgc28gdGhleSBzdGls
bCBuZWVkIHRvIGRvIFBLQ0UgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBvbmx5IGNhc2Ugd2hlcmUgT3BlbklEIENv
bm5lY3QgY2xpZW50cyBkb24ndCBiZW5lZml0IGZyb20gUEtDRSBpcyBpZiB0aGV5IGFyZSBhbHNv
IGNvbmZpZGVudGlhbCBjbGllbnRzLiBQdWJsaWMgY2xpZW50IE9JREMgY2xpZW50cyBzdGlsbCBu
ZWVkIHRvIGRvIFBLQ0UgZXZlbiBpZiB0aGV5IGNoZWNrDQogdGhlIG5vbmNlLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3BlbklEIENv
bm5lY3Qgc2VydmVycyB3b3JraW5nIHdpdGggY29uZmlkZW50aWFsIGNsaWVudHMgc3RpbGwgYmVu
ZWZpdCBmcm9tIFBLQ0UgYmVjYXVzZSB0aGV5IGNhbiB0aGVuIGVuZm9yY2UgdGhlIGF1dGhvcml6
YXRpb24gY29kZSBpbmplY3Rpb24gcHJvdGVjdGlvbiBzZXJ2ZXItc2lkZSZuYnNwO3JhdGhlciZu
YnNwO3RoYW4NCiBjcm9zcyB0aGVpciBmaW5nZXJzIHRoYXQgY2xpZW50cyBpbXBsZW1lbnRlZCB0
aGUgbm9uY2UgY2hlY2sgcHJvcGVybHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHJlYWxseSBkb24ndCB0aGluayBpdCdzIHdvcnRo
IHRoZSBhbW91bnQgb2YgZXhwbGFuYXRpb24gdGhpcyB3aWxsIHRha2UgaW4gdGhlIGZ1dHVyZSB0
byB3cml0ZSBhbiBleGNlcHRpb24gaW50byBPQXV0aCAyLjEgb3IgdGhlIFNlY3VyaXR5IEJDUCBm
b3Igb25seSBzb21lIHR5cGVzIG9mIE9wZW5JRCBDb25uZWN0DQogY2xpZW50cyB3aGVuIGFsbCBj
bGllbnRzIHdvdWxkIGJlbmVmaXQgZnJvbSBQS0NFIGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFhcm9uPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u
IFdlZCwgTWF5IDYsIDIwMjAgYXQgMTA6NDggQU0gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFp
bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+SGVsbG8hDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5XZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1Qg
aW4gT0F1dGggMi4xIGNvZGUgZmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGgg
Mi4wLiBJdCBpcyBub3QgY29tbW9uIGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5v
bmNlIHNvbHZlcyBzb21lIG9mIHRoZSBpc3N1ZXMNCiB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5z
dC4gV2UgdGhpbmsgdGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNv
IHN1cHBvcnQgT0F1dGggMi4wLCBhbmQgaGVuY2UmbmJzcDtoYXZlIHN1cHBvcnQgZm9yIFBLQ0Ug
aWYgZm9sbG93aW5nIGJlc3QgcHJhY3RpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5n
IFBLQ0UgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+LSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0
aCBhcHBsaWNhdGlvbnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NFPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHJlZHVj
ZWQgYXR0YWNrIHN1cmZhY2Ugd2hlbiB1c2luZyZuYnNwOyBTMjU2IGFzIGEgZmluZ2VycHJpbnQg
b2YgdGhlIHZlcmlmaWVyIGlzIHNlbnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRo
ZSBjbGVhciB0ZXh0IHZhbHVlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4tIGVuZm9yY2VtZW50IGJ5IEFTIG5vdCBjbGllbnQgLSBtYWtl
cyBpdCBlYXNpZXIgdG8gaGFuZGxlIGZvciBjbGllbnQgZGV2ZWxvcGVycyBhbmQgQVMgY2FuIGVu
c3VyZSB0aGUgY2hlY2sgaXMgY29uZHVjdGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lk
ZXMgdGhlIHBvdGVudGlhbCBpbXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhv
dyBzaWduaWZpY2FudCBpcyB0aGF0IGltcGFjdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRpY2ssIEFhcm9uLCBhbmQgVG9yc3Rlbjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBzdHls
ZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJo
dHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5i
V0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD00NTI0MzhiYS1kNDI5
LTQ2NTYtYWNlOS1iMjg0NzQ0YmMxNzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N
CjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i
bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0
Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0
bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0
PSIxIiBzdHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAy
NSIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVv
WVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD1lMTA5
OWNhNi1jZTQ5LTQ5OTctYmRlMy01MzRkMjI1ODJlZWIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hp
dGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_MN2PR00MB0688A376C44B8236B7F50F30F5A00MN2PR00MB0688namp_--


From nobody Sun May 10 13:28:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E643A0B99 for ; Sun, 10 May 2020 13:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWHkuqpKipKd for ; Sun, 10 May 2020 13:28:54 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B103A0B93 for ; Sun, 10 May 2020 13:28:53 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id n5so1962311wmd.0 for ; Sun, 10 May 2020 13:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RRDPfeQ9Uah5WDhFQYp4sNtsg8ESAaTV4WM2PLHDllw=; b=bHxYQmxS5Tk7Sc92Z05qLi4BQu70Ium00WOCVAozts2GGQXzFRbJ7XITJe8KTmITUy +5sc3aqTG9/4IaRVEA455oXzZNj0XTVYerg7Qi/pgyzWJ+NfeBDmFYtuXbcYMLZyFuXk b1vvrib4fUYk6k+Bz4hA6VST3Q1vD6RhK4cZs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RRDPfeQ9Uah5WDhFQYp4sNtsg8ESAaTV4WM2PLHDllw=; b=beDlsQ4PJPP65CaAMBf2hTc4p+8yJ7zwrtkxlzDoEyG8OgbDwz6wJFxgSWPtRC9H+E Xr/BLJc130JPi12MseEqq2wjDGvDR+9Hne77Yc+jQ/qJhyWguRN1lamJM/pmys80qYcm Cd3T2v7YRI85BlW/6cd4xLZwi8as8Ey5evZJo7rTJiQ5t6y8iGO/9x3mbrr91vW+HhrE r3zmkDDjuaTutsAwl1jHC2HY5Lr3myRNFbFQZhmOB7lBa5+8eTDyW/J2R05M8jZ9qvnQ XZwT235PHp40d8bJptDRdXU9c5IY1tEJS2I/oux4n3csKF1dUjb7pJ6oxAmQM2kkPd0H t4AQ==
X-Gm-Message-State: AGi0PuZrh9omH/yACe+m8pL1twvJotcSsMhAKdFbzVsfqbhqDF+k0hYV MGEhvli9Q+9HrDt8gIGUqu0X6Q==
X-Google-Smtp-Source: APiQypKT8rDBR9fr0cj0W4lOwDaEwYUG9V4dQXi1EQXtFCpTtwYk+iz6DkqWM8W2qe7YBINbWB0xtg==
X-Received: by 2002:a7b:cbc6:: with SMTP id n6mr8273406wmi.34.1589142532127; Sun, 10 May 2020 13:28:52 -0700 (PDT)
Received: from [10.0.0.2] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id n9sm1618487wmj.5.2020.05.10.13.28.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2020 13:28:51 -0700 (PDT)
From: Neil Madden 
Message-Id: <49198C5C-7D09-40D5-A184-8F4E1835D35B@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1177FA40-9A57-4A8A-B0AA-CE4889CCEF85"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 10 May 2020 21:28:51 +0100
In-Reply-To: 
Cc: Mike Jones , "oauth@ietf.org" , Torsten Lodderstedt 
To: Dick Hardt 
References:     <1C5C5CA8-D414-4507-BAFF-0D7ACFA24005@forgerock.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:28:58 -0000

--Apple-Mail=_1177FA40-9A57-4A8A-B0AA-CE4889CCEF85
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

This is the same as having 2.1 compliance turned off by default. We =
already have a per-client setting to make PKCE mandatory.

If you can turn it off, what=E2=80=99s the point of making it a MUST in =
the spec? What does an optional MUST even mean for an AS to claim 2.1 =
compliance?

> On 10 May 2020, at 21:19, Dick Hardt  wrote:
>=20
> Is there a reason why a server can not support both OAuth 2.0 and =
OAuth 2.1? The version supported could be dependent on the client id, ie =
older clients could still be OAuth 2.0, and newer clients would be OAuth =
2.1, and PKCE would be enforced.
> =E1=90=A7
>=20
> On Sun, May 10, 2020 at 1:05 PM Neil Madden > wrote:
> But if an AS upgrades to OAuth 2.1 then it MUST reject authorization =
requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), =
so this will only be possible when all clients support PKCE.
>=20
> This makes it impossible for a 2.1-compliant AS to also support =
non-PKCE 2.0 clients (i.e., the vast majority of them).
>=20
> I think we can have a 2.1 spec that says clients and servers MUST =
support PKCE without this hard-fail clause. Otherwise I can=E2=80=99t =
see how we=E2=80=99d ever ship with 2.1-compliance enabled =
out-of-the-box.
>=20
> =E2=80=94 Neil
>=20
>> On 10 May 2020, at 20:38, Dick Hardt > wrote:
>>=20
>> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, =
just as the other extensions. Similarly, OAuth 1.0 deployments upgrading =
to OAuth 2.0 was voluntary.=20
>>=20
>> Would you clarify why you think upgrading to OAuth 2.1 would be =
mandatory?
>>=20
>>=20
>> On Sun, May 10, 2020 at 12:02 PM Mike Jones =
> wrote:
>> I agree with actively maintaining and improving the OAuth 2.0 specs =
by adding enhancements that are voluntary to use.  I=E2=80=99ve worked =
on many such improvements, including Dynamic Client Registration, =
Authorization Metadata, the Device Flow, Token Exchange, DPoP, and =
support PAR and RAR, etc.  The issue that=E2=80=99s the subject is the =
current discussion is whether to make use of another enhancement, PKCE, =
mandatory in cases where it=E2=80=99s actually not needed, rather than =
making its use voluntary like the other enhancements, which I certainly =
support.
>>=20
>> =20
>>=20
>>                                                        -- Mike
>>=20
>> =20
>>=20
>> From: Torsten Lodderstedt >=20
>> Sent: Sunday, May 10, 2020 3:15 AM
>> To: Mike Jones >
>> Cc: Daniel Fett >; =
oauth@ietf.org 
>> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>=20
>> =20
>>=20
>> Hi Mike,
>>=20
>> =20
>>=20
>> Mike Jones > schrieb am Fr. 8. Mai 2020 um =
18:55:
>>=20
>> OAuth 2.1 was supposed to not introduce breaking changes.=20
>>=20
>> I cannot remember the WG met that decision. Can you please refer to =
the respective thread?=20
>>=20
>> =20
>>=20
>> Requiring exact redirect URI matching is already a breaking change. =
Do you oppose against this as well?
>>=20
>> =20
>>=20
>> =20
>>=20
>> If you want to do that, please do it in TxAuth instead.
>>=20
>> =20
>>=20
>> Interesting statement. Does it mean you want to conserve OAuth 2.0 =
and force any enhancements/improvements to go into TXAuth? This would =
cause huge migration efforts for existing deployments wanting to benefit =
from those enhancements.
>>=20
>> =20
>>=20
>> I think existing deployments are better served by actively =
maintaining and evolving the 2.x line. For example, PAR and RAR are =
attempts to improve OAuth 2.x and make it usable for new use cases. =
That=E2=80=99s better protection of existing investments than sending =
them of to TXAuth.
>>=20
>> Kind regards,
>>=20
>> Torsten.
>>=20
>> =20
>>=20
>> =20
>>=20
>>                                                        -- Mike
>>=20
>> =20
>>=20
>> From: OAuth > =
On Behalf Of Daniel Fett
>> Sent: Thursday, May 7, 2020 11:50 PM
>> To: oauth@ietf.org 
>> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>=20
>> =20
>>=20
>> +1 to all what Aaron said. Thanks for pointing this out!
>>=20
>> =20
>>=20
>> We need to address this in the security BCP and this will be a =
normative change that affects OpenID Connect Core (just as our current =
recommendation on the usage of nonce).
>>=20
>> =20
>>=20
>> We would then have:
>>=20
>> =20
>>=20
>> - use PKCE, except if you use OIDC with a nonce, then you don't need =
PKCE, except if you are a public client, then you still need PKCE.
>>=20
>> - use state, except if you use PKCE, then you don't need state.
>>=20
>> =20
>>=20
>> I think there are very good reasons to simplify this down to
>>=20
>> =20
>>=20
>> - use PKCE
>>=20
>> - you may or may not use state
>>=20
>> =20
>>=20
>> First and foremost, not many people will understand why there are =
cases when the BCP/OAuth 2.1 mandate PKCE and some where they don't. =
However, understanding why you have to do something is key to =
compliance. The short version "PKCE protects the code; there is a =
specific case where it is not needed, but its better to use it all the =
time" is easy to understand. We will not see many implementations =
following the long version above correctly.
>>=20
>> =20
>>=20
>> Second, we dramatically reduce technical complexity by reducing cases =
that need to be handled. We reduce correctness and compliance testing =
complexity in the same way. We reduce the cost of security analysis, =
which scales really badly to more cases.
>>=20
>> =20
>>=20
>> And finally, using nonce to protect against code injection is less =
robust than PKCE. AS have a better track record than clients when it =
comes to correctly implementing security mechanisms.
>>=20
>> =20
>>=20
>> Yes, this will make a number of implementations non-spec-compliant, =
but I do not think that this is a huge problem. Software needs to adapt =
all the time and a software that has not been changed in a while is =
probably not one you would want to use anyway. We are setting a new goal =
for implementations to meet and eventually, maintained implementations =
will get there.
>>=20
>> =20
>>=20
>> -Daniel
>>=20
>> =20
>>=20
>> =20
>>=20
>> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>>=20
>> Backing up a step or two, there's another point here that I think has =
been missed in these discussions.
>>=20
>> =20
>>=20
>> PKCE solves two problems: stolen authorization codes for public =
clients, and authorization code injection for all clients. We've only =
been talking about authorization code injection on the list so far. The =
quoted section of the security BCP (4.5.3) which says clients can do =
PKCE or use the nonce, is only talking about preventing authorization =
code injection.
>>=20
>> =20
>>=20
>> The nonce parameter solves authorization code injection if the client =
requests an ID token. Public clients using the nonce parameter are still =
susceptible to stolen authorization codes so they still need to do PKCE =
as well.
>>=20
>> =20
>>=20
>> The only case where OpenID Connect clients don't benefit from PKCE is =
if they are also confidential clients. Public client OIDC clients still =
need to do PKCE even if they check the nonce.
>>=20
>> =20
>>=20
>> OpenID Connect servers working with confidential clients still =
benefit from PKCE because they can then enforce the authorization code =
injection protection server-side rather than cross their fingers that =
clients implemented the nonce check properly.
>>=20
>> =20
>>=20
>> I really don't think it's worth the amount of explanation this will =
take in the future to write an exception into OAuth 2.1 or the Security =
BCP for only some types of OpenID Connect clients when all clients would =
benefit from PKCE anyway.
>>=20
>> =20
>>=20
>> Aaron
>>=20
>> =20
>>=20
>> =20
>>=20
>> =20
>>=20
>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt > wrote:
>>=20
>> Hello!
>>=20
>> =20
>>=20
>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is =
best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as the nonce solves some of the issues that PKCE protects against. We =
think that most OpenID Connect implementations also support OAuth 2.0, =
and hence have support for PKCE if following best practices.
>>=20
>> =20
>>=20
>> The advantages or requiring PKCE are:
>>=20
>> =20
>>=20
>> - a simpler programming model across all OAuth applications and =
profiles as they all use PKCE
>>=20
>> =20
>>=20
>> - reduced attack surface when using  S256 as a fingerprint of the =
verifier is sent through the browser instead of the clear text value
>>=20
>> =20
>>=20
>> - enforcement by AS not client - makes it easier to handle for client =
developers and AS can ensure the check is conducted
>>=20
>> =20
>>=20
>> What are disadvantages besides the potential impact to OpenID Connect =
deployments? How significant is that impact?
>>=20
>> =20
>>=20
>> Dick, Aaron, and Torsten
>>=20
>> =20
>>=20
>> =E1=90=A7
>>=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 =

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

>=20


--Apple-Mail=_1177FA40-9A57-4A8A-B0AA-CE4889CCEF85
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

This =
is the same as having 2.1 compliance turned off by default. We already =
have a per-client setting to make PKCE mandatory.

If you can turn it off, what=E2=80=99s =
the point of making it a MUST in the spec? What does an optional MUST =
even mean for an AS to claim 2.1 compliance?

On 10 May 2020, at 21:19, Dick =
Hardt <dick.hardt@gmail.com> wrote:

Is there a reason why a server can not support both OAuth 2.0 =
and OAuth 2.1? The version supported could be dependent on the =
client id, ie older clients could still be OAuth 2.0, and newer clients =
would be OAuth 2.1, and PKCE would be enforced.
3D""=E1=90=A7

On Sun, May =
10, 2020 at 1:05 PM Neil Madden <neil.madden@forgerock.com> wrote:
But if an AS upgrades to OAuth 2.1 then it MUST =
reject authorization requests that don=E2=80=99t include a =
code_challenge (section 4.1.2.1), so this will only be possible when all =
clients support PKCE.

This makes it impossible for a 2.1-compliant AS to also =
support non-PKCE 2.0 clients (i.e., the vast majority of them).

I think we can have a 2.1 spec that says clients and servers =
MUST support PKCE without this hard-fail clause. Otherwise I can=E2=80=99t=
 see how we=E2=80=99d ever ship with 2.1-compliance enabled =
out-of-the-box.

=E2=80=94 Neil

On 10 =
May 2020, at 20:38, Dick Hardt <dick.hardt@gmail.com> =
wrote:

Hi Mike, I would consider =
upgrading to OAuth 2.1 to be voluntary, just as the other extensions. =
Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0 was =
voluntary. 

Would=
 you clarify why you think upgrading to OAuth 2.1 would be =
mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones =
<Michael.Jones=3D40microsoft.com@dmarc.ietf.org> =
wrote:









I agree with actively maintaining and improving the OAuth 2.0 =
specs by adding enhancements that are voluntary to use.  I=E2=80=99ve=
 worked on many such improvements, including Dynamic Client =
Registration, Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and =
RAR, etc.  The issue that=E2=80=99s the subject is the current =
discussion is whether to make use of another enhancement, PKCE, =
mandatory in cases where it=E2=80=99s actually not needed, rather than =
making
 its use voluntary like the other enhancements, which I certainly =
support.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 


From: Torsten Lodderstedt =
<torsten=3D40lodderstedt.net@dmarc.ietf.org>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require =
PKCE?


 




Hi Mike,






 




Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> schrieb am Fr. 8. Mai =
2020 um 18:55:








OAuth 2.1 was supposed to not introduce breaking =
changes. 








I cannot remember the WG met that =
decision. Can you please refer to the respective thread? 




 




Requiring exact redirect URI =
matching is already a breaking change. Do you oppose against this as =
well?




 




 








If you want to do that, please do it in TxAuth =
instead.








 




Interesting statement. Does it =
mean you want to conserve OAuth 2.0 and force any =
enhancements/improvements to go into TXAuth? This would cause huge =
migration efforts for existing deployments wanting to benefit from those =
enhancements.




 




I think existing deployments are =
better served by actively maintaining and evolving the 2.x line. For =
example, PAR and RAR are attempts to improve OAuth 2.x and make it =
usable for new use cases. That=E2=80=99s better protection of existing =
investments
 than sending them of to TXAuth.




Kind regards,




Torsten.




 








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




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




 


+1 to all what Aaron said. Thanks =
for pointing this out!




 




We need to address this in the =
security BCP and this will be a normative change that affects OpenID =
Connect Core (just as our current recommendation on the usage of =
nonce).




 




We would then have:




 




- use PKCE, except if you use =
OIDC with a nonce, then you don't need PKCE, except if you are a public =
client, then you still need PKCE.




- use state, except if you use =
PKCE, then you don't need state.




 




I think there are very good =
reasons to simplify this down to





 




- use PKCE




- you may or may not use state




 




First and foremost, not many =
people will understand why there are cases when the BCP/OAuth 2.1 =
mandate PKCE and some where they don't. However, understanding
why you have to do something is key to compliance. The =
short version "PKCE protects the code; there is a specific case where it =
is not needed, but its better to use it all the time" is easy to =
understand. We will not see many implementations following
 the long version above correctly.
=




 




Second, we dramatically reduce =
technical complexity by reducing cases that need to be handled. We =
reduce correctness and compliance testing complexity in the same way. We =
reduce
 the cost of security analysis, which scales really badly to more =
cases.




 




And finally, using nonce to =
protect against code injection is less robust than PKCE. AS have a =
better track record than clients when it comes to correctly implementing =
security
 mechanisms. 




 




Yes, this will make a number of =
implementations non-spec-compliant, but I do not think that this is a =
huge problem. Software needs to adapt all the time and a software that =
has
 not been changed in a while is probably not one you would want to use =
anyway. We are setting a new goal for implementations to meet and =
eventually, maintained implementations will get there.




 




-Daniel




 




 




Am 08.05.20 um 01:38 schrieb =
Aaron Parecki:








Backing up a step or two, there's =
another point here that I think has been missed in these discussions.



 




PKCE solves two problems: stolen =
authorization codes for public clients, and authorization code injection =
for all clients. We've only been talking about authorization code =
injection
 on the list so far. The quoted section of the security BCP (4.5.3) =
which says clients can do PKCE or use the nonce, is only talking about =
preventing authorization code injection.




 




The nonce parameter solves =
authorization code injection if the client requests an ID token. Public =
clients using the nonce parameter are still susceptible to stolen =
authorization
 codes so they still need to do PKCE as well.




 




The only case where OpenID =
Connect clients don't benefit from PKCE is if they are also confidential =
clients. Public client OIDC clients still need to do PKCE even if they =
check
 the nonce.




 




OpenID Connect servers working =
with confidential clients still benefit from PKCE because they can then =
enforce the authorization code injection protection =
server-side rather than
 cross their fingers that clients implemented the nonce check =
properly.




 




I really don't think it's worth =
the amount of explanation this will take in the future to write an =
exception into OAuth 2.1 or the Security BCP for only some types of =
OpenID Connect
 clients when all clients would benefit from PKCE anyway.




 




Aaron




 






 


 




On Wed, May 6, 2020 at 10:48 AM =
Dick Hardt <dick.hardt@gmail.com> wrote:








Hello!



 




We would like to have PKCE be a =
MUST in OAuth 2.1 code flows. This is best practice for OAuth 2.0. It is =
not common in OpenID Connect servers as the nonce solves some of the =
issues
 that PKCE protects against. We think that most OpenID Connect =
implementations also support OAuth 2.0, and hence have support for =
PKCE if following best practices.




 




The advantages or requiring PKCE =
are:




 




- a simpler programming model =
across all OAuth applications and profiles as they all use PKCE




 




- reduced attack surface when =
using  S256 as a fingerprint of the verifier is sent through the =
browser instead of the clear text value




 




- enforcement by AS not client - =
makes it easier to handle for client developers and AS can ensure the =
check is conducted




 




What are disadvantages besides =
the potential impact to OpenID Connect deployments? How significant is =
that impact?




 




Dick, Aaron, and Torsten




 








=E1=90=A7








 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


 




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


3D""=E1=90=A7

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




=

--Apple-Mail=_1177FA40-9A57-4A8A-B0AA-CE4889CCEF85--


From nobody Sun May 10 13:33:05 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93B43A0B9A for ; Sun, 10 May 2020 13:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TylqehZWccD for ; Sun, 10 May 2020 13:32:56 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59E83A0B99 for ; Sun, 10 May 2020 13:32:55 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id e25so7272868ljg.5 for ; Sun, 10 May 2020 13:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NLujWLRM9umz8WE8TaPLEUhh9Cm8kYp9da5tC6wjnwk=; b=QHcRM5NGBv30TVIaT9QTNf5e+yed7WQnRBw6EyhRS9xRcG+DYCCGk0ROd5AxKJol7S F+Dvxwm2yQfsK9slunDkLedSNDw++YSYduSelvVl934PQ/W11Bsi/Y9hRLqXGG29kCv1 LTOx6yl00YfCWKAydBj3hTZAocZzEGklB91Q0npSL04dAwfphNC4XlobA+0aYAvuwnl/ PA5R2q/nCyJe6igI6THIoDqMcGQZn8ny0etYvybY8d6Tpoc8kmAO4YeKVZvFNc0OKIKt mHGewSvcgdJ1rPCt5v8CKF/LHBCA1mTreLdH57RGi08/IMAXPkEEmRxMRnqNYclV+8jo SXfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NLujWLRM9umz8WE8TaPLEUhh9Cm8kYp9da5tC6wjnwk=; b=CPs+fRbtzIgH3fXSMH0pQDx0GQj7el5lQdochUsvaqQjzz5IIA+lQMo0s30E954Rab eovxbs9nJi5/aHcAuXcfFNxAJHf3pyYvy4zUl6Z+FEwAU6aujYptG37oz4WvsQV6TYb+ cFLGpv4KG4/IsNpBAfW1WGT6bT4t+gbjEYek8/9ZtDIptYRSks7zqfRr3IgmULkb0wLJ tSIaBLe0GtYdGuogPGZIgDM+oT8Et2nJfOKuACcYqY6Zgm6k1zmh3+25CTRH2ckvnqvS r0+KFWEMl2SrXhAAMw8Y7SmyPNC7buhLtY08borsykBDpqRV56kN8jM0YBJmo8kkRkYr Eh4g==
X-Gm-Message-State: AOAM532eK9wyqJihiJFSaoQsHr6fLpyEnbYwcisbO2BNDk7ucGZkibfx 0/6gfE7+uvt8DIn23eb1qXMeR5LYW2Y60CltHz0=
X-Google-Smtp-Source: ABdhPJxEthsh5SI/XGKi7uyhrVzc0EAcpg3eFrq3BO+cjDn8g9SkoVmvafZzjcG1PiDKAQcdvOqueGkT1V+7GxWa3Io=
X-Received: by 2002:a2e:9605:: with SMTP id v5mr8302319ljh.102.1589142773537;  Sun, 10 May 2020 13:32:53 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 10 May 2020 13:32:27 -0700
Message-ID: 
To: Mike Jones 
Cc: Torsten Lodderstedt , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000083a0f705a5512251"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:33:04 -0000

--00000000000083a0f705a5512251
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

We are NOT saying that an OAuth 2.0 compatible server is OAuth 2.1
compatible. For example, an OAuth 2.0 compatible server does not have to
support PKCE, support the implicit grant, support the Resource Owner
Password Credentials grant, support bearer tokens in the query string of
the URI, etc.
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-12

 We have stated the goal to be OAuth 2.0 with best practices. As noted
earlier, we are now discussing what is best practices.

Per my other email, no one is requiring a deployment to upgrade, and a
deployment may support both legacy OAuth 2.0 clients, and OAuth 2.1 clients
at the same time. We can add some non-normative text to explain that if you
like.

On Sun, May 10, 2020 at 1:24 PM Mike Jones 
wrote:

> The difference is that OAuth 2.1 is supposed to compatible with OAuth 2.0
> (which is my whole goal here), whereas OAuth 2.0 was incompatible with
> OAuth 1.0 by design.
>
>
>
> *From:* Dick Hardt 
> *Sent:* Sunday, May 10, 2020 12:58 PM
> *To:* Mike Jones 
> *Cc:* Torsten Lodderstedt ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Just as upgrading to OAuth 2.0 from OAuth 1.0 was voluntary, why is
> upgrading to OAuth 2.1 not voluntary?
>
>
>
> OAuth 2.0 obsoleted OAuth 1.0, just as OAuth 2.1 is obsoleting OAuth 2.1.
> Our goal is for new deployments, that are reading the drafts, to use the
> best practices.
>
>
>
> If existing deployments don't want the advantages of a new version or
> extension, there is nobody forcing them to upgrade -- hence my confusion =
on
> your statement that it is "mandatory". Upgrading to OAuth 2.0 from OAuth
> 1.0 was not mandatory, and some deployments still use OAuth 1.0 today.
>
>
>
>
>
>
>
> =E1=90=A7
>
>
>
> On Sun, May 10, 2020 at 12:51 PM Mike Jones 
> wrote:
>
> If I=E2=80=99m not mistaken, the OAuth 2.1 draft is intended to make OAut=
h 2.0
> (RFC 6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC
> 5849) obsolete.  That=E2=80=99s what makes me think developers would view=
 updating
> as mandatory.  If you=E2=80=99re willing to remove the =E2=80=9Creplaces =
6749=E2=80=9D clause from
> the draft, then there would be no perception problem, as it would be clea=
r
> that adoption of 2.1 would be voluntary, just like the other extension
> specs.
>
>
>
> *From:* Dick Hardt 
> *Sent:* Sunday, May 10, 2020 12:38 PM
> *To:* Mike Jones 
> *Cc:* Torsten Lodderstedt ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
> the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
> 2.0 was voluntary.
>
>
>
> Would you clarify why you think upgrading to OAuth 2.1 would be mandatory=
?
>
>
>
>
>
> On Sun, May 10, 2020 at 12:02 PM Mike Jones  40microsoft.com@dmarc.ietf.org> wrote:
>
> I agree with actively maintaining and improving the OAuth 2.0 specs by
> adding enhancements that are voluntary to use.  I=E2=80=99ve worked on ma=
ny such
> improvements, including Dynamic Client Registration, Authorization
> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
> etc.  The issue that=E2=80=99s the subject is the current discussion is w=
hether to
> make use of another enhancement, PKCE, mandatory in cases where it=E2=80=
=99s
> actually not needed, rather than making its use voluntary like the other
> enhancements, which I certainly support.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Torsten Lodderstedt 
> *Sent:* Sunday, May 10, 2020 3:15 AM
> *To:* Mike Jones 
> *Cc:* Daniel Fett ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hi Mike,
>
>
>
> Mike Jones  schrieb am Fr=
.
> 8. Mai 2020 um 18:55:
>
> OAuth 2.1 was supposed to not introduce breaking changes.
>
> I cannot remember the WG met that decision. Can you please refer to the
> respective thread?
>
>
>
> Requiring exact redirect URI matching is already a breaking change. Do yo=
u
> oppose against this as well?
>
>
>
>
>
> If you want to do that, please do it in TxAuth instead.
>
>
>
> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
> force any enhancements/improvements to go into TXAuth? This would cause
> huge migration efforts for existing deployments wanting to benefit from
> those enhancements.
>
>
>
> I think existing deployments are better served by actively maintaining an=
d
> evolving the 2.x line. For example, PAR and RAR are attempts to improve
> OAuth 2.x and make it usable for new use cases. That=E2=80=99s better pro=
tection of
> existing investments than sending them of to TXAuth.
>
> Kind regards,
>
> Torsten.
>
>
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Daniel Fett
> *Sent:* Thursday, May 7, 2020 11:50 PM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> +1 to all what Aaron said. Thanks for pointing this out!
>
>
>
> We need to address this in the security BCP and this will be a normative
> change that affects OpenID Connect Core (just as our current recommendati=
on
> on the usage of nonce).
>
>
>
> We would then have:
>
>
>
> - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE=
,
> except if you are a public client, then you still need PKCE.
>
> - use state, except if you use PKCE, then you don't need state.
>
>
>
> I think there are very good reasons to simplify this down to
>
>
>
> - use PKCE
>
> - you may or may not use state
>
>
>
> First and foremost, not many people will understand why there are cases
> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
> understanding *why* you have to do something is key to compliance. The
> short version "PKCE protects the code; there is a specific case where it =
is
> not needed, but its better to use it all the time" is easy to understand.
> We will not see many implementations following the long version above
> correctly.
>
>
>
> Second, we dramatically reduce technical complexity by reducing cases tha=
t
> need to be handled. We reduce correctness and compliance testing complexi=
ty
> in the same way. We reduce the cost of security analysis, which scales
> really badly to more cases.
>
>
>
> And finally, using nonce to protect against code injection is less robust
> than PKCE. AS have a better track record than clients when it comes to
> correctly implementing security mechanisms.
>
>
>
> Yes, this will make a number of implementations non-spec-compliant, but I
> do not think that this is a huge problem. Software needs to adapt all the
> time and a software that has not been changed in a while is probably not
> one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will g=
et
> there.
>
>
>
> -Daniel
>
>
>
>
>
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>
> Backing up a step or two, there's another point here that I think has bee=
n
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE a=
s
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP fo=
r
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> =E1=90=A7
>
> =E1=90=A7

--00000000000083a0f705a5512251
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


We are NOT saying that an OAuth 2.0 compa=
tible server is OAuth 2.1 compatible. For example, an OAuth 2.0 compatible =
server does not have to support PKCE, support the implicit grant, support t=
he Resource Owner Password Credentials grant, support bearer tokens in the =
query string of the URI, etc.=C2=A0https://tools.ietf.org/html/draft-pa=
recki-oauth-v2-1-02#section-12

=C2=A0We have stated =
the goal to be OAuth 2.0 with best practices. As noted earlier, we are now =
discussing what is best practices.=C2=A0

Per my ot=
her email, no one is requiring a deployment to upgrade, and a deployment ma=
y support both legacy OAuth 2.0 clients, and OAuth 2.1 clients at the same =
time. We can add some non-normative text to explain that if you like.
=


=
On Sun, May 10, 2020 at 1:24 PM Mike Jones <Michael.Jones@microsoft.com> wrote:











The difference is=
 that OAuth 2.1 is supposed to compatible with OAuth 2.0 (which is my whole=
 goal here), whereas OAuth 2.0 was incompatible with OAuth 1.0 by design.


=C2=A0<=
/u>




From: Dick Hardt <dick.hardt@gmail.com> 

Sent: Sunday, May 10, 2020 12:58 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Torsten Lodderstedt <torsten@lodderstedt.net>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0




Just as upgrading to OAuth 2.0 from OAuth 1.0 was vo=
luntary, why is upgrading to OAuth 2.1 not voluntary?=C2=A0



=C2=A0






OAuth 2.0 obsoleted OAuth 1.0, just as OAuth 2.1 is =
obsoleting OAuth 2.1. Our goal is for new deployments, that are reading the=
 drafts, to use the best practices.




=C2=A0






If existing deployments don't want the advantage=
s of a new version or extension, there is nobody forcing them to upgrade --=
 hence my confusion on your statement that it is "mandatory". Upg=
rading to OAuth 2.0 from OAuth 1.0 was not mandatory,
 and some deployments still use OAuth 1.0 today.








=C2=A0






=C2=A0






=C2=A0








=
=
=E1=90=A7




=C2=A0






On Sun, May 10, 2020 at 12:51 PM Mike Jones <Michael.Jones@=
microsoft.com> wrote:










If I=E2=80=99m no=
t mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0 (RFC 6749) ob=
solete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC 5849)
 obsolete.=C2=A0 That=E2=80=99s what makes me think developers would view u=
pdating as mandatory.=C2=A0 If you=E2=80=99re willing to remove the =E2=80=
=9Creplaces 6749=E2=80=9D clause from the draft, then there would be no per=
ception problem, as it would be clear that adoption of 2.1 would be volunta=
ry,
 just like the other extension specs.


=C2=A0<=
/u>




From: Dick Hardt <dick.hardt@gmail.com>


Sent: Sunday, May 10, 2020 12:38 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Torsten Lodderstedt <torsten@lodderstedt.net>;
oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hi Mike, I would consider upgrading to OAuth 2.1 to =
be voluntary, just as the other extensions. Similarly, OAuth 1.0 deployment=
s upgrading to OAuth 2.0 was voluntary.=C2=A0




=C2=A0






Would you clarify why you think upgrading=C2=A0to OA=
uth 2.1 would be mandatory?






=C2=A0






=C2=A0






On Sun, May 10, 2020 at 12:02 PM Mike Jones <Mich=
ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:










I agree with acti=
vely maintaining and improving the OAuth 2.0 specs by adding enhancements t=
hat are voluntary to use.=C2=A0 I=E2=80=99ve worked on many such improvemen=
ts,
 including Dynamic Client Registration, Authorization Metadata, the Device =
Flow, Token Exchange, DPoP, and support PAR and RAR, etc.=C2=A0 The issue t=
hat=E2=80=99s the subject is the current discussion is whether to make use =
of another enhancement, PKCE, mandatory in cases
 where it=E2=80=99s actually not needed, rather than making its use volunta=
ry like the other enhancements, which I certainly support.=



=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Torsten Lodderstedt <torsten=3D40lodderst=
edt.net@dmarc.ietf.org>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>;
oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>




=C2=A0






Hi Mike,








=C2=A0






Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.o=
rg> schrieb am Fr. 8. Mai 2020 um 18:55:










OAuth 2.1 was sup=
posed to not introduce breaking changes.=C2=A0










I cannot remember the WG met that decision. Can you =
please refer to the respective thread?=C2=A0






=C2=A0






Requiring exact redirect URI matching is already a b=
reaking change. Do you oppose against this as well?






=C2=A0






=C2=A0










If you want to do=
 that, please do it in TxAuth instead.










=C2=A0






Interesting statement. Does it mean you want to cons=
erve OAuth 2.0 and force any enhancements/improvements to go into TXAuth? T=
his would cause huge migration efforts for existing
 deployments wanting to benefit from those enhancements.






=C2=A0






I think existing deployments are better served by ac=
tively maintaining and evolving the 2.x line. For example, PAR and RAR are =
attempts to improve OAuth 2.x and make it usable for
 new use cases. That=E2=80=99s better protection of existing investments th=
an sending them of to TXAuth.






Kind regards,






Torsten.






=C2=A0










=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?






=C2=A0




+1 to all what Aaron said. Thanks for pointing this =
out!






=C2=A0






We need to address this in the security BCP and this=
 will be a normative change that affects OpenID Connect Core (just as our c=
urrent recommendation on the usage of nonce).






=C2=A0






We would then have:






=C2=A0






- use PKCE, except if you use OIDC with a nonce, the=
n you don't need PKCE, except if you are a public client, then you stil=
l need PKCE.






- use state, except if you use PKCE, then you don=
9;t need state.






=C2=A0






I think there are very good reasons to simplify this=
 down to







=C2=A0






- use PKCE






- you may or may not use state






=C2=A0






First and foremost, not many people will understand =
why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where they=
 don't. However, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.






=C2=A0






Second, we dramatically reduce technical complexity =
by reducing cases that need to be handled. We reduce correctness and compli=
ance testing complexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.=







=C2=A0






And finally, using nonce to protect against code inj=
ection is less robust than PKCE. AS have a better track record than clients=
 when it comes to correctly implementing security
 mechanisms. 






=C2=A0






Yes, this will make a number of implementations non-=
spec-compliant, but I do not think that this is a huge problem. Software ne=
eds to adapt all the time and a software that has
 not been changed in a while is probably not one you would want to use anyw=
ay. We are setting a new goal for implementations to meet and eventually, m=
aintained implementations will get there.






=C2=A0






-Daniel






=C2=A0






=C2=A0






Am 08.05.20 um 01:38 schrieb Aaron Parecki:










Backing up a step or two, there's another point =
here that I think has been missed in these discussions.





=C2=A0






PKCE solves two problems: stolen authorization codes=
 for public clients, and authorization code injection for all clients. We&#=
39;ve only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.






=C2=A0






The nonce parameter solves authorization code inject=
ion if the client requests an ID token. Public clients using the nonce para=
meter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.






=C2=A0






The only case where OpenID Connect clients don't=
 benefit from PKCE is if they are also confidential clients. Public client =
OIDC clients still need to do PKCE even if they check
 the nonce.






=C2=A0






OpenID Connect servers working with confidential cli=
ents still benefit from PKCE because they can then enforce the authorizatio=
n code injection protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.<=
/u>






=C2=A0






I really don't think it's worth the amount o=
f explanation this will take in the future to write an exception into OAuth=
 2.1 or the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.






=C2=A0






Aaron






=C2=A0








=C2=A0




=C2=A0






On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:










Hello!





=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7










=C2=A0

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0






_______________________________________________

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










=E1=90=A7

















3D""=
=E1=90=A7


--00000000000083a0f705a5512251--


From nobody Sun May 10 13:36:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DA73A0B9E for ; Sun, 10 May 2020 13:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 357e6XIak1iN for ; Sun, 10 May 2020 13:36:05 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD6A3A0B99 for ; Sun, 10 May 2020 13:36:04 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id 8so3027960lfp.4 for ; Sun, 10 May 2020 13:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4DIB1ujQQDHyIjtZhnOYbmMWG/v2FS7s/Q+9NJImTRo=; b=cvv+U6nroDEI57rSh2xzPqzJivt17LtAfowYhoGY26wY1Ztq6e6Z5vvnAW6OBmcuM+ EnH6/etM1tqVlKhfWzhWwX+Fcdd/Dr514FDOHTyEOSYM0a2eIAvj1KanPHaUFYkz6eeD SWvGid4glhFaqdNNcnejOlptYmp/gbrlyk8sUr93wh9QEBI1EkL40p9cReVQcF8ZfZsO NXJD/tT+CpFXR4SyAUsl+vOkA6OsOxlQt7N8bRrV59Tvzf/ZDNu76A/NKWjjYy5Duzto ePEmz8Reo8i8Twcilc5A3mGsWHuldAcjc+Q0XgK6nm0qUHZ+5tDw6nLFKRx4FMY3Lcuw NCHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4DIB1ujQQDHyIjtZhnOYbmMWG/v2FS7s/Q+9NJImTRo=; b=mjNyb/pvwSD/g5AbolHcNOxI7RO5BITmfLYrtJxuUcqWFjWR13vumxavzasCvq76vo 8zt5ze4gfQtNaKX6wtqDkF1BHwlaFVzgbgic8xVsOtMND48CQHQgHScJnbu/i+AoxiNF LzgLb0kgc87Zriom/1Nz/0sJQf7ork8SqFNcPlL8B5ItMMAOEwFAmR2i/+5f5Br9T+fI LSHot1unNxMgqI2F0STJSNaNXQ/+WfljcrGZ2BUh/A8zKb1hHaQx21cR7rVsC6rCwGwY CEJiewIUe/w+YGDDBqPj4bINPve793HyNF6lvLP+PEFfF8xa+cfI/a5pN01Rz8gnuYTV KKvA==
X-Gm-Message-State: AOAM532xp2ARZrJhqo6JsKQ7PyDkH4zFncKfGPsbKjc6UN/SvZprc6DC HXfbsOjSHA/fzu9XA0eKdIlXKiW7OKOdBpYXHW8Oovyt
X-Google-Smtp-Source: ABdhPJya+JdIgxvLPCZ44OedFZpvU9i2gwW5FlRYqpTnZu6iedaoJhJoGAVLUjsaMSo8/9T27J9wi8/lBAtP0Z6YTN4=
X-Received: by 2002:a19:80ca:: with SMTP id b193mr8378765lfd.7.1589142962769;  Sun, 10 May 2020 13:36:02 -0700 (PDT)
MIME-Version: 1.0
References:     <1C5C5CA8-D414-4507-BAFF-0D7ACFA24005@forgerock.com>  <49198C5C-7D09-40D5-A184-8F4E1835D35B@forgerock.com>
In-Reply-To: <49198C5C-7D09-40D5-A184-8F4E1835D35B@forgerock.com>
From: Dick Hardt 
Date: Sun, 10 May 2020 13:35:36 -0700
Message-ID: 
To: Neil Madden 
Cc: Mike Jones ,  "oauth@ietf.org" ,  Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary="000000000000cb14c705a5512d8d"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:36:10 -0000

--000000000000cb14c705a5512d8d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sounds like your clients that have set PKCE to be mandatory will then be
OAuth 2.1 compliant with no extra work.

A deployment can decide when they want to be compliant. That is not the
specifications decision. I'm unclear on what point you are wanting to make
below.


On Sun, May 10, 2020 at 1:28 PM Neil Madden 
wrote:

> This is the same as having 2.1 compliance turned off by default. We
> already have a per-client setting to make PKCE mandatory.
>
> If you can turn it off, what=E2=80=99s the point of making it a MUST in t=
he spec?
> What does an optional MUST even mean for an AS to claim 2.1 compliance?
>
> On 10 May 2020, at 21:19, Dick Hardt  wrote:
>
> Is there a reason why a server can not support both OAuth 2.0 and OAuth
> 2.1? The version supported could be dependent on the client id, ie older
> clients could still be OAuth 2.0, and newer clients would be OAuth 2.1, a=
nd
> PKCE would be enforced.
> =E1=90=A7
>
> On Sun, May 10, 2020 at 1:05 PM Neil Madden 
> wrote:
>
>> But if an AS upgrades to OAuth 2.1 then it MUST reject authorization
>> requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), =
so this
>> will only be possible when all clients support PKCE.
>>
>> This makes it impossible for a 2.1-compliant AS to also support non-PKCE
>> 2.0 clients (i.e., the vast majority of them).
>>
>> I think we can have a 2.1 spec that says clients and servers MUST suppor=
t
>> PKCE without this hard-fail clause. Otherwise I can=E2=80=99t see how we=
=E2=80=99d ever
>> ship with 2.1-compliance enabled out-of-the-box.
>>
>> =E2=80=94 Neil
>>
>> On 10 May 2020, at 20:38, Dick Hardt  wrote:
>>
>> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just a=
s
>> the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAut=
h
>> 2.0 was voluntary.
>>
>> Would you clarify why you think upgrading to OAuth 2.1 would be mandator=
y?
>>
>>
>> On Sun, May 10, 2020 at 12:02 PM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote:
>>
>>> I agree with actively maintaining and improving the OAuth 2.0 specs by
>>> adding enhancements that are voluntary to use.  I=E2=80=99ve worked on =
many such
>>> improvements, including Dynamic Client Registration, Authorization
>>> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RA=
R,
>>> etc.  The issue that=E2=80=99s the subject is the current discussion is=
 whether to
>>> make use of another enhancement, PKCE, mandatory in cases where it=E2=
=80=99s
>>> actually not needed, rather than making its use voluntary like the othe=
r
>>> enhancements, which I certainly support.
>>>
>>>
>>>
>>>                                                        -- Mike
>>>
>>>
>>>
>>> *From:* Torsten Lodderstedt 
>>> *Sent:* Sunday, May 10, 2020 3:15 AM
>>> *To:* Mike Jones 
>>> *Cc:* Daniel Fett ; oauth@ietf.org
>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>
>>>
>>>
>>> Hi Mike,
>>>
>>>
>>>
>>> Mike Jones  schrieb am
>>> Fr. 8. Mai 2020 um 18:55:
>>>
>>> OAuth 2.1 was supposed to not introduce breaking changes.
>>>
>>> I cannot remember the WG met that decision. Can you please refer to the
>>> respective thread?
>>>
>>>
>>>
>>> Requiring exact redirect URI matching is already a breaking change. Do
>>> you oppose against this as well?
>>>
>>>
>>>
>>>
>>>
>>> If you want to do that, please do it in TxAuth instead.
>>>
>>>
>>>
>>> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
>>> force any enhancements/improvements to go into TXAuth? This would cause
>>> huge migration efforts for existing deployments wanting to benefit from
>>> those enhancements.
>>>
>>>
>>>
>>> I think existing deployments are better served by actively maintaining
>>> and evolving the 2.x line. For example, PAR and RAR are attempts to imp=
rove
>>> OAuth 2.x and make it usable for new use cases. That=E2=80=99s better p=
rotection of
>>> existing investments than sending them of to TXAuth.
>>>
>>> Kind regards,
>>>
>>> Torsten.
>>>
>>>
>>>
>>>
>>>
>>>                                                        -- Mike
>>>
>>>
>>>
>>> *From:* OAuth  *On Behalf Of *Daniel Fett
>>> *Sent:* Thursday, May 7, 2020 11:50 PM
>>> *To:* oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>
>>>
>>>
>>> +1 to all what Aaron said. Thanks for pointing this out!
>>>
>>>
>>>
>>> We need to address this in the security BCP and this will be a normativ=
e
>>> change that affects OpenID Connect Core (just as our current recommenda=
tion
>>> on the usage of nonce).
>>>
>>>
>>>
>>> We would then have:
>>>
>>>
>>>
>>> - use PKCE, except if you use OIDC with a nonce, then you don't need
>>> PKCE, except if you are a public client, then you still need PKCE.
>>>
>>> - use state, except if you use PKCE, then you don't need state.
>>>
>>>
>>>
>>> I think there are very good reasons to simplify this down to
>>>
>>>
>>>
>>> - use PKCE
>>>
>>> - you may or may not use state
>>>
>>>
>>>
>>> First and foremost, not many people will understand why there are cases
>>> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
>>> understanding *why* you have to do something is key to compliance. The
>>> short version "PKCE protects the code; there is a specific case where i=
t is
>>> not needed, but its better to use it all the time" is easy to understan=
d.
>>> We will not see many implementations following the long version above
>>> correctly.
>>>
>>>
>>>
>>> Second, we dramatically reduce technical complexity by reducing cases
>>> that need to be handled. We reduce correctness and compliance testing
>>> complexity in the same way. We reduce the cost of security analysis, wh=
ich
>>> scales really badly to more cases.
>>>
>>>
>>>
>>> And finally, using nonce to protect against code injection is less
>>> robust than PKCE. AS have a better track record than clients when it co=
mes
>>> to correctly implementing security mechanisms.
>>>
>>>
>>>
>>> Yes, this will make a number of implementations non-spec-compliant, but
>>> I do not think that this is a huge problem. Software needs to adapt all=
 the
>>> time and a software that has not been changed in a while is probably no=
t
>>> one you would want to use anyway. We are setting a new goal for
>>> implementations to meet and eventually, maintained implementations will=
 get
>>> there.
>>>
>>>
>>>
>>> -Daniel
>>>
>>>
>>>
>>>
>>>
>>> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>>>
>>> Backing up a step or two, there's another point here that I think has
>>> been missed in these discussions.
>>>
>>>
>>>
>>> PKCE solves two problems: stolen authorization codes for public clients=
,
>>> and authorization code injection for all clients. We've only been talki=
ng
>>> about authorization code injection on the list so far. The quoted secti=
on
>>> of the security BCP (4.5.3) which says clients can do PKCE or use the
>>> nonce, is only talking about preventing authorization code injection.
>>>
>>>
>>>
>>> The nonce parameter solves authorization code injection if the client
>>> requests an ID token. Public clients using the nonce parameter are stil=
l
>>> susceptible to stolen authorization codes so they still need to do PKCE=
 as
>>> well.
>>>
>>>
>>>
>>> The only case where OpenID Connect clients don't benefit from PKCE is i=
f
>>> they are also confidential clients. Public client OIDC clients still ne=
ed
>>> to do PKCE even if they check the nonce.
>>>
>>>
>>>
>>> OpenID Connect servers working with confidential clients still benefit
>>> from PKCE because they can then enforce the authorization code injectio=
n
>>> protection server-side rather than cross their fingers that clients
>>> implemented the nonce check properly.
>>>
>>>
>>>
>>> I really don't think it's worth the amount of explanation this will tak=
e
>>> in the future to write an exception into OAuth 2.1 or the Security BCP =
for
>>> only some types of OpenID Connect clients when all clients would benefi=
t
>>> from PKCE anyway.
>>>
>>>
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote=
:
>>>
>>> Hello!
>>>
>>>
>>>
>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>>> best practice for OAuth 2.0. It is not common in OpenID Connect servers=
 as
>>> the nonce solves some of the issues that PKCE protects against. We thin=
k
>>> that most OpenID Connect implementations also support OAuth 2.0, and
>>> hence have support for PKCE if following best practices.
>>>
>>>
>>>
>>> The advantages or requiring PKCE are:
>>>
>>>
>>>
>>> - a simpler programming model across all OAuth applications and profile=
s
>>> as they all use PKCE
>>>
>>>
>>>
>>> - reduced attack surface when using  S256 as a fingerprint of the
>>> verifier is sent through the browser instead of the clear text value
>>>
>>>
>>>
>>> - enforcement by AS not client - makes it easier to handle for client
>>> developers and AS can ensure the check is conducted
>>>
>>>
>>>
>>> What are disadvantages besides the potential impact to OpenID Connect
>>> deployments? How significant is that impact?
>>>
>>>
>>>
>>> Dick, Aaron, and Torsten
>>>
>>>
>>>
>>> =E1=90=A7
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> OAuth mailing list
>>>
>>> OAuth@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> =E1=90=A7
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
> =E1=90=A7

--000000000000cb14c705a5512d8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sounds like your clients that have =
set PKCE to be mandatory will then be OAuth 2.1 compliant with no extra wor=
k.=C2=A0

A deployment can decide when they want to be co=
mpliant. That is not the specifications decision. I'm unclear on what p=
oint you are wanting to make below.=C2=A0


On Sun, May 10=
, 2020 at 1:28 PM Neil Madden <neil.madden@forgerock.com> wrote:
This=
 is the same as having 2.1 compliance turned off by default. We already hav=
e a per-client setting to make PKCE mandatory.

If you ca=
n turn it off, what=E2=80=99s the point of making it a MUST in the spec? Wh=
at does an optional MUST even mean for an AS to claim 2.1 compliance?

On 10 May 2020, at 21=
:19, Dick Hardt <dick.hardt@gmail.com> wrote:

Is th=
ere a reason why a server can not support both OAuth 2.0 and OAuth 2.1? The=
 version supported could be dependent=C2=A0on the client id, ie older clien=
ts could still be OAuth 2.0, and newer clients would be OAuth 2.1, and PKCE=
 would be enforced.
3D""=E1=90=A7

On Sun, May 10, 202=
0 at 1:05 PM Neil Madden <neil.madden@forgerock.com> wrote:
But if an AS upgrades to OAu=
th 2.1 then it MUST reject authorization requests that don=E2=80=99t includ=
e a code_challenge (section 4.1.2.1), so this will only be possible when al=
l clients support PKCE.

This makes it impossible for a 2=
.1-compliant AS to also support non-PKCE 2.0 clients (i.e., the vast majori=
ty of them).

I think we can have a 2.1 spec tha=
t says clients and servers MUST support PKCE without this hard-fail clause.=
 Otherwise I can=E2=80=99t see how we=E2=80=99d ever ship with 2.1-complian=
ce enabled out-of-the-box.

=E2=80=94 Neil

On 10 May 2020, at 20:38, D=
ick Hardt <dic=
k.hardt@gmail.com> wrote:

Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, jus=
t as the other extensions. Similarly, OAuth 1.0 deployments upgrading to OA=
uth 2.0 was voluntary.=C2=A0

Would you clarify why you t=
hink upgrading=C2=A0to OAuth 2.1 would be mandatory?


On=
 Sun, May 10, 2020 at 12:02 PM Mike Jones <Michael.Jones=3D40microsoft.com@dmar=
c.ietf.org> wrote:









I agree with=
 actively maintaining and improving the OAuth 2.0 specs by adding enhanceme=
nts that are voluntary to use.=C2=A0 I=E2=80=99ve worked on many such impro=
vements, including Dynamic Client Registration, Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR, =
etc.=C2=A0 The issue that=E2=80=99s the subject is the current discussion i=
s whether to make use of another enhancement, PKCE, mandatory in cases wher=
e it=E2=80=99s actually not needed, rather than making
 its use voluntary like the other enhancements, which I certainly support.<=
u>
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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>
=C2=A0<=
u>


=
From: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org<=
/a>>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>


=C2=A0




Hi Mike,






=C2=A0




Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.i=
etf.org> schrieb am Fr. 8. Mai 2020 um 18:55:








OAuth 2.1 wa=
s supposed to not introduce breaking changes.=C2=A0







I cannot remember the WG met that decision. Can=
 you please refer to the respective thread?=C2=A0




=C2=A0




Requiring exact redirect URI matching is alread=
y a breaking change. Do you oppose against this as well?




=C2=A0




=C2=A0








If you want =
to do that, please do it in TxAuth instead.








=C2=A0




Interesting statement. Does it mean you want to=
 conserve OAuth 2.0 and force any enhancements/improvements to go into TXAu=
th? This would cause huge migration efforts for existing deployments wantin=
g to benefit from those enhancements.




=C2=A0




I think existing deployments are better served =
by actively maintaining and evolving the 2.x line. For example, PAR and RAR=
 are attempts to improve OAuth 2.x and make it usable for new use cases. Th=
at=E2=80=99s better protection of existing investments
 than sending them of to TXAuth.




Kind regards,




Torsten.




=C2=A0








=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0


+1 to all what Aaron said. Thanks for pointing =
this out!




=C2=A0




We need to address this in the security BCP and=
 this will be a normative change that affects OpenID Connect Core (just as =
our current recommendation on the usage of nonce).




=C2=A0




We would then have:




=C2=A0




- use PKCE, except if you use OIDC with a nonce=
, then you don't need PKCE, except if you are a public client, then you=
 still need PKCE.




- use state, except if you use PKCE, then you d=
on't need state.




=C2=A0




I think there are very good reasons to simplify=
 this down to





=C2=A0




- use PKCE




- you may or may not use state



=C2=A0




First and foremost, not many people will unders=
tand why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where=
 they don't. However, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.




=C2=A0




Second, we dramatically reduce technical comple=
xity by reducing cases that need to be handled. We reduce correctness and c=
ompliance testing complexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.=





=C2=A0




And finally, using nonce to protect against cod=
e injection is less robust than PKCE. AS have a better track record than cl=
ients when it comes to correctly implementing security
 mechanisms. 




=C2=A0




Yes, this will make a number of implementations=
 non-spec-compliant, but I do not think that this is a huge problem. Softwa=
re needs to adapt all the time and a software that has
 not been changed in a while is probably not one you would want to use anyw=
ay. We are setting a new goal for implementations to meet and eventually, m=
aintained implementations will get there.




=C2=A0




-Daniel




=C2=A0




=C2=A0




Am 08.05.20 um 01:38 schrieb Aaron Parecki:<=
/u>








Backing up a step or two, there's another p=
oint here that I think has been missed in these discussions.



=C2=A0




PKCE solves two problems: stolen authorization =
codes for public clients, and authorization code injection for all clients.=
 We've only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.




=C2=A0




The nonce parameter solves authorization code i=
njection if the client requests an ID token. Public clients using the nonce=
 parameter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.




=C2=A0




The only case where OpenID Connect clients don&=
#39;t benefit from PKCE is if they are also confidential clients. Public cl=
ient OIDC clients still need to do PKCE even if they check
 the nonce.




=C2=A0




OpenID Connect servers working with confidentia=
l clients still benefit from PKCE because they can then enforce the authori=
zation code injection protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.<=
/u>




=C2=A0




I really don't think it's worth the amo=
unt of explanation this will take in the future to write an exception into =
OAuth 2.1 or the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.




=C2=A0




Aaron




=C2=A0






=C2=A0


=C2=A0




On Wed, May 6, 2020 at 10:48 AM Dick Hardt <=
dick.hardt@gmail.=
com> wrote:








Hello!



=C2=A0




We would like to have PKCE be a MUST in OAuth 2=
.1 code flows. This is best practice for OAuth 2.0. It is not common in Ope=
nID Connect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.




=C2=A0




The advantages or requiring PKCE are:=





=C2=A0




- a simpler programming model across all OAuth =
applications and profiles as they all use PKCE




=C2=A0




- reduced attack surface when using=C2=A0 S256 =
as a fingerprint of the verifier is sent through the browser instead of the=
 clear text value




=C2=A0




- enforcement by AS not client - makes it easie=
r to handle for client developers and AS can ensure the check is conducted<=
u>




=C2=A0




What are disadvantages besides the potential im=
pact to OpenID Connect deployments? How significant is that impact?<=
u>




=C2=A0




Dick, Aaron, and Torsten




=C2=A0








=E1=90=
=A7








=C2=A0<=
/u>


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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


=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


3D""=E1=90=A7

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



3D""=E1=90=A7


--000000000000cb14c705a5512d8d--


From nobody Sun May 10 13:46:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3893A0BAF for ; Sun, 10 May 2020 13:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvUmsybeoDDp for ; Sun, 10 May 2020 13:46:29 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C92B3A0BAD for ; Sun, 10 May 2020 13:46:29 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id x17so8446907wrt.5 for ; Sun, 10 May 2020 13:46:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=shK/4gPVthULbg0Pj9j6LbjFIyaqZoxNx8acN5xNeX0=; b=HStrO+7oklkdsESjqhJ6/nKr/JDJPU+0VU+G05nbh2n5UARNNpY/oCBWq+/sRqbhz+ 8hgJGca34rFf/C32dnHoWM0QJRN+rZr6AThAS/3nz5Eatu0Z3Ds+t1H2FegMjCMO7hx4 w60nvprryb2l77nJf5Pb39am7q3D7Iz+ejE+s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=shK/4gPVthULbg0Pj9j6LbjFIyaqZoxNx8acN5xNeX0=; b=C+0zp0nshI8INOICT3kCyEX1r8xk4ZovHZuaAiB5+xzDMt24vsZL0TDqfAIhaiDMpM fPFGCjP24crzyF5GQmTKmklDofoaJ5EixuQ7sEuMk/N55IFC0kt1tDaMIzmqaqxXFBUq v5fwUTZq1mmUFxZ87hI2DXUfmvLba2lAJ+PfIu4jmlsHzIhJkRwrlWtjussWQX5TZa+S dm6x5+aMDDKRmGQxlyqx3QwMJgo01O2AJlIYTktzY5HX5G2EUr0vMXA/9LIJP3vFpoay bVmjDcxc7cJlEjh5WkAPhSAWHeacioDcSIddhqtAdUFw/mHDFNpFbe1GgdIf1BQURUFS CXMQ==
X-Gm-Message-State: AGi0PuZIzixnj849COOBcTMuK0++/zhf6UrjOVWrN6VHe1MJLX2Ji8gr KTPe7TVAYNzrM80W/bUtYTtlQQ==
X-Google-Smtp-Source: APiQypJ5eF8K25L/baOpA7y40uWMaInz0Qj6nFCBEZlON6N5bvoKP9DfAJZRkV3zN8L5NmE8BYcmlA==
X-Received: by 2002:a5d:6803:: with SMTP id w3mr4469175wru.151.1589143587335;  Sun, 10 May 2020 13:46:27 -0700 (PDT)
Received: from [10.0.0.2] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id f8sm14196635wrm.8.2020.05.10.13.46.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2020 13:46:26 -0700 (PDT)
From: Neil Madden 
Message-Id: <367838B9-A1F2-4CF3-8C06-BC2547C8FB29@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_53698793-6244-4F94-A42E-62CDD32E3420"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 10 May 2020 21:46:26 +0100
In-Reply-To: 
Cc: Mike Jones , "oauth@ietf.org" , Torsten Lodderstedt 
To: Dick Hardt 
References:     <1C5C5CA8-D414-4507-BAFF-0D7ACFA24005@forgerock.com>  <49198C5C-7D09-40D5-A184-8F4E1835D35B@forgerock.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:46:36 -0000

--Apple-Mail=_53698793-6244-4F94-A42E-62CDD32E3420
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Let=E2=80=99s go back to basics. Why is this clause a MUST in the 2.1 =
spec? What does that accomplish?

It doesn=E2=80=99t provide any security benefit - an attacker can just =
as easily send a code_challenge as a legitimate client, there=E2=80=99s =
no secret involved. So enforcing PKCE in this way doesn=E2=80=99t =
prevent any direct attacks. Presumably then making it a hard fail is =
designed to drive adoption of PKCE - turning the thumbscrews on clients =
that otherwise wouldn=E2=80=99t bother?

But if we are saying that an AS can happily support legacy 2.0 clients =
without PKCE then the pressure of the MUST clause evaporates and they =
are free to ignore it again. What=E2=80=99s the incentive for an AS =
deployment to ever enforce 2.1 compliance if all it adds is a potential =
incompatibility with no security gain? (Given that servers and clients =
can already support PKCE if they wish).

All I can see this doing is delaying adoption of 2.1 by ASes.

=E2=80=94 Neil


> On 10 May 2020, at 21:35, Dick Hardt  wrote:
>=20
> Sounds like your clients that have set PKCE to be mandatory will then =
be OAuth 2.1 compliant with no extra work.=20
>=20
> A deployment can decide when they want to be compliant. That is not =
the specifications decision. I'm unclear on what point you are wanting =
to make below.=20
>=20
>=20
> On Sun, May 10, 2020 at 1:28 PM Neil Madden > wrote:
> This is the same as having 2.1 compliance turned off by default. We =
already have a per-client setting to make PKCE mandatory.
>=20
> If you can turn it off, what=E2=80=99s the point of making it a MUST =
in the spec? What does an optional MUST even mean for an AS to claim 2.1 =
compliance?
>=20
>> On 10 May 2020, at 21:19, Dick Hardt > wrote:
>>=20
>> Is there a reason why a server can not support both OAuth 2.0 and =
OAuth 2.1? The version supported could be dependent on the client id, ie =
older clients could still be OAuth 2.0, and newer clients would be OAuth =
2.1, and PKCE would be enforced.
>> =E1=90=A7
>>=20
>> On Sun, May 10, 2020 at 1:05 PM Neil Madden =
> wrote:
>> But if an AS upgrades to OAuth 2.1 then it MUST reject authorization =
requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), =
so this will only be possible when all clients support PKCE.
>>=20
>> This makes it impossible for a 2.1-compliant AS to also support =
non-PKCE 2.0 clients (i.e., the vast majority of them).
>>=20
>> I think we can have a 2.1 spec that says clients and servers MUST =
support PKCE without this hard-fail clause. Otherwise I can=E2=80=99t =
see how we=E2=80=99d ever ship with 2.1-compliance enabled =
out-of-the-box.
>>=20
>> =E2=80=94 Neil
>>=20
>>> On 10 May 2020, at 20:38, Dick Hardt > wrote:
>>>=20
>>> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, =
just as the other extensions. Similarly, OAuth 1.0 deployments upgrading =
to OAuth 2.0 was voluntary.=20
>>>=20
>>> Would you clarify why you think upgrading to OAuth 2.1 would be =
mandatory?
>>>=20
>>>=20
>>> On Sun, May 10, 2020 at 12:02 PM Mike Jones =
> wrote:
>>> I agree with actively maintaining and improving the OAuth 2.0 specs =
by adding enhancements that are voluntary to use.  I=E2=80=99ve worked =
on many such improvements, including Dynamic Client Registration, =
Authorization Metadata, the Device Flow, Token Exchange, DPoP, and =
support PAR and RAR, etc.  The issue that=E2=80=99s the subject is the =
current discussion is whether to make use of another enhancement, PKCE, =
mandatory in cases where it=E2=80=99s actually not needed, rather than =
making its use voluntary like the other enhancements, which I certainly =
support.
>>>=20
>>> =20
>>>=20
>>>                                                        -- Mike
>>>=20
>>> =20
>>>=20
>>> From: Torsten Lodderstedt >=20
>>> Sent: Sunday, May 10, 2020 3:15 AM
>>> To: Mike Jones >
>>> Cc: Daniel Fett >; =
oauth@ietf.org 
>>> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>=20
>>> =20
>>>=20
>>> Hi Mike,
>>>=20
>>> =20
>>>=20
>>> Mike Jones > schrieb am Fr. 8. Mai 2020 um =
18:55:
>>>=20
>>> OAuth 2.1 was supposed to not introduce breaking changes.=20
>>>=20
>>> I cannot remember the WG met that decision. Can you please refer to =
the respective thread?=20
>>>=20
>>> =20
>>>=20
>>> Requiring exact redirect URI matching is already a breaking change. =
Do you oppose against this as well?
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>> If you want to do that, please do it in TxAuth instead.
>>>=20
>>> =20
>>>=20
>>> Interesting statement. Does it mean you want to conserve OAuth 2.0 =
and force any enhancements/improvements to go into TXAuth? This would =
cause huge migration efforts for existing deployments wanting to benefit =
from those enhancements.
>>>=20
>>> =20
>>>=20
>>> I think existing deployments are better served by actively =
maintaining and evolving the 2.x line. For example, PAR and RAR are =
attempts to improve OAuth 2.x and make it usable for new use cases. =
That=E2=80=99s better protection of existing investments than sending =
them of to TXAuth.
>>>=20
>>> Kind regards,
>>>=20
>>> Torsten.
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>>                                                        -- Mike
>>>=20
>>> =20
>>>=20
>>> From: OAuth > =
On Behalf Of Daniel Fett
>>> Sent: Thursday, May 7, 2020 11:50 PM
>>> To: oauth@ietf.org 
>>> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>=20
>>> =20
>>>=20
>>> +1 to all what Aaron said. Thanks for pointing this out!
>>>=20
>>> =20
>>>=20
>>> We need to address this in the security BCP and this will be a =
normative change that affects OpenID Connect Core (just as our current =
recommendation on the usage of nonce).
>>>=20
>>> =20
>>>=20
>>> We would then have:
>>>=20
>>> =20
>>>=20
>>> - use PKCE, except if you use OIDC with a nonce, then you don't need =
PKCE, except if you are a public client, then you still need PKCE.
>>>=20
>>> - use state, except if you use PKCE, then you don't need state.
>>>=20
>>> =20
>>>=20
>>> I think there are very good reasons to simplify this down to
>>>=20
>>> =20
>>>=20
>>> - use PKCE
>>>=20
>>> - you may or may not use state
>>>=20
>>> =20
>>>=20
>>> First and foremost, not many people will understand why there are =
cases when the BCP/OAuth 2.1 mandate PKCE and some where they don't. =
However, understanding why you have to do something is key to =
compliance. The short version "PKCE protects the code; there is a =
specific case where it is not needed, but its better to use it all the =
time" is easy to understand. We will not see many implementations =
following the long version above correctly.
>>>=20
>>> =20
>>>=20
>>> Second, we dramatically reduce technical complexity by reducing =
cases that need to be handled. We reduce correctness and compliance =
testing complexity in the same way. We reduce the cost of security =
analysis, which scales really badly to more cases.
>>>=20
>>> =20
>>>=20
>>> And finally, using nonce to protect against code injection is less =
robust than PKCE. AS have a better track record than clients when it =
comes to correctly implementing security mechanisms.
>>>=20
>>> =20
>>>=20
>>> Yes, this will make a number of implementations non-spec-compliant, =
but I do not think that this is a huge problem. Software needs to adapt =
all the time and a software that has not been changed in a while is =
probably not one you would want to use anyway. We are setting a new goal =
for implementations to meet and eventually, maintained implementations =
will get there.
>>>=20
>>> =20
>>>=20
>>> -Daniel
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>>>=20
>>> Backing up a step or two, there's another point here that I think =
has been missed in these discussions.
>>>=20
>>> =20
>>>=20
>>> PKCE solves two problems: stolen authorization codes for public =
clients, and authorization code injection for all clients. We've only =
been talking about authorization code injection on the list so far. The =
quoted section of the security BCP (4.5.3) which says clients can do =
PKCE or use the nonce, is only talking about preventing authorization =
code injection.
>>>=20
>>> =20
>>>=20
>>> The nonce parameter solves authorization code injection if the =
client requests an ID token. Public clients using the nonce parameter =
are still susceptible to stolen authorization codes so they still need =
to do PKCE as well.
>>>=20
>>> =20
>>>=20
>>> The only case where OpenID Connect clients don't benefit from PKCE =
is if they are also confidential clients. Public client OIDC clients =
still need to do PKCE even if they check the nonce.
>>>=20
>>> =20
>>>=20
>>> OpenID Connect servers working with confidential clients still =
benefit from PKCE because they can then enforce the authorization code =
injection protection server-side rather than cross their fingers that =
clients implemented the nonce check properly.
>>>=20
>>> =20
>>>=20
>>> I really don't think it's worth the amount of explanation this will =
take in the future to write an exception into OAuth 2.1 or the Security =
BCP for only some types of OpenID Connect clients when all clients would =
benefit from PKCE anyway.
>>>=20
>>> =20
>>>=20
>>> Aaron
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt > wrote:
>>>=20
>>> Hello!
>>>=20
>>> =20
>>>=20
>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This =
is best practice for OAuth 2.0. It is not common in OpenID Connect =
servers as the nonce solves some of the issues that PKCE protects =
against. We think that most OpenID Connect implementations also support =
OAuth 2.0, and hence have support for PKCE if following best practices.
>>>=20
>>> =20
>>>=20
>>> The advantages or requiring PKCE are:
>>>=20
>>> =20
>>>=20
>>> - a simpler programming model across all OAuth applications and =
profiles as they all use PKCE
>>>=20
>>> =20
>>>=20
>>> - reduced attack surface when using  S256 as a fingerprint of the =
verifier is sent through the browser instead of the clear text value
>>>=20
>>> =20
>>>=20
>>> - enforcement by AS not client - makes it easier to handle for =
client developers and AS can ensure the check is conducted
>>>=20
>>> =20
>>>=20
>>> What are disadvantages besides the potential impact to OpenID =
Connect deployments? How significant is that impact?
>>>=20
>>> =20
>>>=20
>>> Dick, Aaron, and Torsten
>>>=20
>>> =20
>>>=20
>>> =E1=90=A7
>>>=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 =

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

>>=20
>=20
> =E1=90=A7


--Apple-Mail=_53698793-6244-4F94-A42E-62CDD32E3420
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Let=E2=80=99s go back to basics. Why is this clause a =
MUST in the 2.1 spec? What does that accomplish?

It doesn=E2=80=99t provide any security benefit - =
an attacker can just as easily send a code_challenge as a legitimate =
client, there=E2=80=99s no secret involved. So enforcing PKCE in this =
way doesn=E2=80=99t prevent any direct attacks. Presumably then making =
it a hard fail is designed to drive adoption of PKCE - turning the =
thumbscrews on clients that otherwise wouldn=E2=80=99t =
bother?

But if we are saying that an =
AS can happily support legacy 2.0 clients without PKCE then the pressure =
of the MUST clause evaporates and they are free to ignore it again. =
What=E2=80=99s the incentive for an AS deployment to ever enforce 2.1 =
compliance if all it adds is a potential incompatibility with no =
security gain? (Given that servers and clients can already support PKCE =
if they wish).

All I can see this =
doing is delaying adoption of 2.1 by ASes.

=E2=80=94 Neil


On 10 May 2020, at 21:35, Dick Hardt <dick.hardt@gmail.com> wrote:

Sounds like your clients =
that have set PKCE to be mandatory will then be OAuth 2.1 compliant with =
no extra work. 

A=
 deployment can decide when they want to be compliant. That is not the =
specifications decision. I'm unclear on what point you are wanting to =
make below. 


On Sun, May 10, 2020 at 1:28 PM Neil Madden <neil.madden@forgerock.com> wrote:
This is the same as having 2.1 compliance turned =
off by default. We already have a per-client setting to make PKCE =
mandatory.

If you =
can turn it off, what=E2=80=99s the point of making it a MUST in the =
spec? What does an optional MUST even mean for an AS to claim 2.1 =
compliance?

On 10 May 2020, at 21:19, Dick Hardt <dick.hardt@gmail.com> wrote:

Is there a reason why a server =
can not support both OAuth 2.0 and OAuth 2.1? The version supported =
could be dependent on the client id, ie older clients could still =
be OAuth 2.0, and newer clients would be OAuth 2.1, and PKCE would be =
enforced.
3D""=E1=90=A7

On Sun, May =
10, 2020 at 1:05 PM Neil Madden <neil.madden@forgerock.com> wrote:
But if an AS upgrades =
to OAuth 2.1 then it MUST reject authorization requests that don=E2=80=99t=
 include a code_challenge (section 4.1.2.1), so this will only be =
possible when all clients support PKCE.

This makes it impossible for a =
2.1-compliant AS to also support non-PKCE 2.0 clients (i.e., the vast =
majority of them).

I think we can have a 2.1 spec that says =
clients and servers MUST support PKCE without this hard-fail clause. =
Otherwise I can=E2=80=99t see how we=E2=80=99d ever ship with =
2.1-compliance enabled out-of-the-box.

=E2=80=94 Neil

On 10 May 2020, at 20:38, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi =
Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as =
the other extensions. Similarly, OAuth 1.0 deployments upgrading to =
OAuth 2.0 was voluntary. 

Would you clarify why you think upgrading to OAuth 2.1 =
would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones =
<Michael.Jones=3D40microsoft.com@dmarc.ietf.org> =
wrote:









I agree with actively maintaining and improving the OAuth 2.0 =
specs by adding enhancements that are voluntary to use.  I=E2=80=99ve=
 worked on many such improvements, including Dynamic Client =
Registration, Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and =
RAR, etc.  The issue that=E2=80=99s the subject is the current =
discussion is whether to make use of another enhancement, PKCE, =
mandatory in cases where it=E2=80=99s actually not needed, rather than =
making
 its use voluntary like the other enhancements, which I certainly =
support.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 


From: Torsten Lodderstedt =
<torsten=3D40lodderstedt.net@dmarc.ietf.org>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require =
PKCE?


 




Hi Mike,






 




Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> schrieb am Fr. 8. Mai =
2020 um 18:55:








OAuth 2.1 was supposed to not introduce breaking =
changes. 








I cannot remember the WG met that =
decision. Can you please refer to the respective thread? 




 




Requiring exact redirect URI =
matching is already a breaking change. Do you oppose against this as =
well?




 




 








If you want to do that, please do it in TxAuth =
instead.








 




Interesting statement. Does it =
mean you want to conserve OAuth 2.0 and force any =
enhancements/improvements to go into TXAuth? This would cause huge =
migration efforts for existing deployments wanting to benefit from those =
enhancements.




 




I think existing deployments are =
better served by actively maintaining and evolving the 2.x line. For =
example, PAR and RAR are attempts to improve OAuth 2.x and make it =
usable for new use cases. That=E2=80=99s better protection of existing =
investments
 than sending them of to TXAuth.




Kind regards,




Torsten.




 








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




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




 


+1 to all what Aaron said. Thanks =
for pointing this out!




 




We need to address this in the =
security BCP and this will be a normative change that affects OpenID =
Connect Core (just as our current recommendation on the usage of =
nonce).




 




We would then have:




 




- use PKCE, except if you use =
OIDC with a nonce, then you don't need PKCE, except if you are a public =
client, then you still need PKCE.




- use state, except if you use =
PKCE, then you don't need state.




 




I think there are very good =
reasons to simplify this down to





 




- use PKCE




- you may or may not use state




 




First and foremost, not many =
people will understand why there are cases when the BCP/OAuth 2.1 =
mandate PKCE and some where they don't. However, understanding
why you have to do something is key to compliance. The =
short version "PKCE protects the code; there is a specific case where it =
is not needed, but its better to use it all the time" is easy to =
understand. We will not see many implementations following
 the long version above correctly.
=




 




Second, we dramatically reduce =
technical complexity by reducing cases that need to be handled. We =
reduce correctness and compliance testing complexity in the same way. We =
reduce
 the cost of security analysis, which scales really badly to more =
cases.




 




And finally, using nonce to =
protect against code injection is less robust than PKCE. AS have a =
better track record than clients when it comes to correctly implementing =
security
 mechanisms. 




 




Yes, this will make a number of =
implementations non-spec-compliant, but I do not think that this is a =
huge problem. Software needs to adapt all the time and a software that =
has
 not been changed in a while is probably not one you would want to use =
anyway. We are setting a new goal for implementations to meet and =
eventually, maintained implementations will get there.




 




-Daniel




 




 




Am 08.05.20 um 01:38 schrieb =
Aaron Parecki:








Backing up a step or two, there's =
another point here that I think has been missed in these discussions.



 




PKCE solves two problems: stolen =
authorization codes for public clients, and authorization code injection =
for all clients. We've only been talking about authorization code =
injection
 on the list so far. The quoted section of the security BCP (4.5.3) =
which says clients can do PKCE or use the nonce, is only talking about =
preventing authorization code injection.




 




The nonce parameter solves =
authorization code injection if the client requests an ID token. Public =
clients using the nonce parameter are still susceptible to stolen =
authorization
 codes so they still need to do PKCE as well.




 




The only case where OpenID =
Connect clients don't benefit from PKCE is if they are also confidential =
clients. Public client OIDC clients still need to do PKCE even if they =
check
 the nonce.




 




OpenID Connect servers working =
with confidential clients still benefit from PKCE because they can then =
enforce the authorization code injection protection =
server-side rather than
 cross their fingers that clients implemented the nonce check =
properly.




 




I really don't think it's worth =
the amount of explanation this will take in the future to write an =
exception into OAuth 2.1 or the Security BCP for only some types of =
OpenID Connect
 clients when all clients would benefit from PKCE anyway.




 




Aaron




 






 


 




On Wed, May 6, 2020 at 10:48 AM =
Dick Hardt <dick.hardt@gmail.com> wrote:








Hello!



 




We would like to have PKCE be a =
MUST in OAuth 2.1 code flows. This is best practice for OAuth 2.0. It is =
not common in OpenID Connect servers as the nonce solves some of the =
issues
 that PKCE protects against. We think that most OpenID Connect =
implementations also support OAuth 2.0, and hence have support for =
PKCE if following best practices.




 




The advantages or requiring PKCE =
are:




 




- a simpler programming model =
across all OAuth applications and profiles as they all use PKCE




 




- reduced attack surface when =
using  S256 as a fingerprint of the verifier is sent through the =
browser instead of the clear text value




 




- enforcement by AS not client - =
makes it easier to handle for client developers and AS can ensure the =
check is conducted




 




What are disadvantages besides =
the potential impact to OpenID Connect deployments? How significant is =
that impact?




 




Dick, Aaron, and Torsten




 








=E1=90=A7








 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


 




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


3D""=E1=90=A7

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




3D""=E1=90=A7


=

--Apple-Mail=_53698793-6244-4F94-A42E-62CDD32E3420--


From nobody Sun May 10 17:35:13 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA123A0C22 for ; Sun, 10 May 2020 17:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7LIsLLObkgO for ; Sun, 10 May 2020 17:35:06 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DBA3A0C20 for ; Sun, 10 May 2020 17:35:05 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id h4so7577206ljg.12 for ; Sun, 10 May 2020 17:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cUYW3aa4NjYXjWyWikE3Q4JY/gleq7Vt9/Tza31VtHc=; b=q4xSK2YRfiZDMk3VYXCZG8G3ZGYpIBJQL+wmCR2o9aLJ2jiRyRJbj2d7M9LwtjD24p aonCei/quFB1zQuSjFdfnna/60HXLTcrcYZAHTl2ZwQqlJ+fNNpKWkRSA+tKlihYPjVA 4ycD5YGx14QXdYrLPs3N/Ekb6WIa9d49NcigDRY4JUx0Yff+1nRYH7U+1SBqd45SYHMj k6XbL+l1yKNPcbPWd7jFMSd5shZVSlN5PilvHZDiyRuj+s+hihyYvzj/zCj7NnkbfyJt wQaSzQXGuybl5OFgCCd9N2AYWn+i3wHSreY318D9JtFY5OApcwTpJeGEtLU55oQtoKy2 3Jxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cUYW3aa4NjYXjWyWikE3Q4JY/gleq7Vt9/Tza31VtHc=; b=PgapJC3SMz8rzlIO36nbP37XnpPh6w+z0V9N5k1laVEirSGgPVbDjgkXuC4XLZvnY9 C6PXknfw89YcPTKAA4HVDz8hFW5hPvdDrwYcbjYO6KsnYCaiV0tGPg4/Obwzq6NmCvEc otq80GYZ6Pt+CiNE1fuR6diut3A9XbmczDv0OkGZ1xdUo8Rr6IOCqDO2Ot74WINMOI+0 /GQMBg3rTvK8plMvug2k8qGJnf6yRbxa53ObEl090Qeus794V966SkMtDNAuRVSnr2Sq UeqFsVlio3ow4hjDpOInW/NTvNbzVfoEDN8ysfCD7Bj6NjtD7B0MYn7Si846kU3IP4BB POqg==
X-Gm-Message-State: AOAM533Jr1JV5ncU6DcjPJonTHQ0pFdBAJ5ARkj9Th1lejqRdNZ0Y9VG QsV/VovO2XOaFWD3q/eW8olKTxKjG/xn203ulg4=
X-Google-Smtp-Source: ABdhPJwxpg2BFOkTNtWk+dXcPsSITN+jfa548gi4ETe+ySZUzTy1S1tiSr/on1+WMGvwS5xczTpgMe/N5OxdS6HLklw=
X-Received: by 2002:a2e:b44c:: with SMTP id o12mr7982297ljm.240.1589157303194;  Sun, 10 May 2020 17:35:03 -0700 (PDT)
MIME-Version: 1.0
References:     <1C5C5CA8-D414-4507-BAFF-0D7ACFA24005@forgerock.com>  <49198C5C-7D09-40D5-A184-8F4E1835D35B@forgerock.com>  <367838B9-A1F2-4CF3-8C06-BC2547C8FB29@forgerock.com>
In-Reply-To: <367838B9-A1F2-4CF3-8C06-BC2547C8FB29@forgerock.com>
From: Dick Hardt 
Date: Sun, 10 May 2020 17:34:36 -0700
Message-ID: 
To: Neil Madden 
Cc: Mike Jones ,  "oauth@ietf.org" ,  Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary="0000000000008c98e605a5548432"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 00:35:11 -0000

--0000000000008c98e605a5548432
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It is a MUST to enforce consistency across all clients, and therefore to
improve security for all clients.

An AS can decide to be OAuth 2.1 for all new clients, and encourage
existing clients to migrate to OAuth 2.1 (add support for PKCE).

If the client wants OAuth 2.1, the AS will enforce it.

I don't follow your logic below wrt. what an attacker will do.


On Sun, May 10, 2020 at 1:46 PM Neil Madden 
wrote:

> Let=E2=80=99s go back to basics. Why is this clause a MUST in the 2.1 spe=
c? What
> does that accomplish?
>
> It doesn=E2=80=99t provide any security benefit - an attacker can just as=
 easily
> send a code_challenge as a legitimate client, there=E2=80=99s no secret i=
nvolved.
> So enforcing PKCE in this way doesn=E2=80=99t prevent any direct attacks.
> Presumably then making it a hard fail is designed to drive adoption of PK=
CE
> - turning the thumbscrews on clients that otherwise wouldn=E2=80=99t both=
er?
>
> But if we are saying that an AS can happily support legacy 2.0 clients
> without PKCE then the pressure of the MUST clause evaporates and they are
> free to ignore it again. What=E2=80=99s the incentive for an AS deploymen=
t to ever
> enforce 2.1 compliance if all it adds is a potential incompatibility with
> no security gain? (Given that servers and clients can already support PKC=
E
> if they wish).
>
> All I can see this doing is delaying adoption of 2.1 by ASes.
>
> =E2=80=94 Neil
>
>
> On 10 May 2020, at 21:35, Dick Hardt  wrote:
>
> Sounds like your clients that have set PKCE to be mandatory will then be
> OAuth 2.1 compliant with no extra work.
>
> A deployment can decide when they want to be compliant. That is not the
> specifications decision. I'm unclear on what point you are wanting to mak=
e
> below.
>
>
> On Sun, May 10, 2020 at 1:28 PM Neil Madden 
> wrote:
>
>> This is the same as having 2.1 compliance turned off by default. We
>> already have a per-client setting to make PKCE mandatory.
>>
>> If you can turn it off, what=E2=80=99s the point of making it a MUST in =
the spec?
>> What does an optional MUST even mean for an AS to claim 2.1 compliance?
>>
>> On 10 May 2020, at 21:19, Dick Hardt  wrote:
>>
>> Is there a reason why a server can not support both OAuth 2.0 and OAuth
>> 2.1? The version supported could be dependent on the client id, ie older
>> clients could still be OAuth 2.0, and newer clients would be OAuth 2.1, =
and
>> PKCE would be enforced.
>> =E1=90=A7
>>
>> On Sun, May 10, 2020 at 1:05 PM Neil Madden 
>> wrote:
>>
>>> But if an AS upgrades to OAuth 2.1 then it MUST reject authorization
>>> requests that don=E2=80=99t include a code_challenge (section 4.1.2.1),=
 so this
>>> will only be possible when all clients support PKCE.
>>>
>>> This makes it impossible for a 2.1-compliant AS to also support non-PKC=
E
>>> 2.0 clients (i.e., the vast majority of them).
>>>
>>> I think we can have a 2.1 spec that says clients and servers MUST
>>> support PKCE without this hard-fail clause. Otherwise I can=E2=80=99t s=
ee how we=E2=80=99d
>>> ever ship with 2.1-compliance enabled out-of-the-box.
>>>
>>> =E2=80=94 Neil
>>>
>>> On 10 May 2020, at 20:38, Dick Hardt  wrote:
>>>
>>> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just
>>> as the other extensions. Similarly, OAuth 1.0 deployments upgrading to
>>> OAuth 2.0 was voluntary.
>>>
>>> Would you clarify why you think upgrading to OAuth 2.1 would be
>>> mandatory?
>>>
>>>
>>> On Sun, May 10, 2020 at 12:02 PM Mike Jones >> 40microsoft.com@dmarc.ietf.org> wrote:
>>>
>>>> I agree with actively maintaining and improving the OAuth 2.0 specs by
>>>> adding enhancements that are voluntary to use.  I=E2=80=99ve worked on=
 many such
>>>> improvements, including Dynamic Client Registration, Authorization
>>>> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and R=
AR,
>>>> etc.  The issue that=E2=80=99s the subject is the current discussion i=
s whether to
>>>> make use of another enhancement, PKCE, mandatory in cases where it=E2=
=80=99s
>>>> actually not needed, rather than making its use voluntary like the oth=
er
>>>> enhancements, which I certainly support.
>>>>
>>>>
>>>>
>>>>                                                        -- Mike
>>>>
>>>>
>>>>
>>>> *From:* Torsten Lodderstedt 
>>>> *Sent:* Sunday, May 10, 2020 3:15 AM
>>>> *To:* Mike Jones 
>>>> *Cc:* Daniel Fett ; oauth@ietf.org
>>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>
>>>>
>>>>
>>>> Hi Mike,
>>>>
>>>>
>>>>
>>>> Mike Jones  schrieb am
>>>> Fr. 8. Mai 2020 um 18:55:
>>>>
>>>> OAuth 2.1 was supposed to not introduce breaking changes.
>>>>
>>>> I cannot remember the WG met that decision. Can you please refer to th=
e
>>>> respective thread?
>>>>
>>>>
>>>>
>>>> Requiring exact redirect URI matching is already a breaking change. Do
>>>> you oppose against this as well?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> If you want to do that, please do it in TxAuth instead.
>>>>
>>>>
>>>>
>>>> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
>>>> force any enhancements/improvements to go into TXAuth? This would caus=
e
>>>> huge migration efforts for existing deployments wanting to benefit fro=
m
>>>> those enhancements.
>>>>
>>>>
>>>>
>>>> I think existing deployments are better served by actively maintaining
>>>> and evolving the 2.x line. For example, PAR and RAR are attempts to im=
prove
>>>> OAuth 2.x and make it usable for new use cases. That=E2=80=99s better =
protection of
>>>> existing investments than sending them of to TXAuth.
>>>>
>>>> Kind regards,
>>>>
>>>> Torsten.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                                                        -- Mike
>>>>
>>>>
>>>>
>>>> *From:* OAuth  *On Behalf Of *Daniel Fett
>>>> *Sent:* Thursday, May 7, 2020 11:50 PM
>>>> *To:* oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>
>>>>
>>>>
>>>> +1 to all what Aaron said. Thanks for pointing this out!
>>>>
>>>>
>>>>
>>>> We need to address this in the security BCP and this will be a
>>>> normative change that affects OpenID Connect Core (just as our current
>>>> recommendation on the usage of nonce).
>>>>
>>>>
>>>>
>>>> We would then have:
>>>>
>>>>
>>>>
>>>> - use PKCE, except if you use OIDC with a nonce, then you don't need
>>>> PKCE, except if you are a public client, then you still need PKCE.
>>>>
>>>> - use state, except if you use PKCE, then you don't need state.
>>>>
>>>>
>>>>
>>>> I think there are very good reasons to simplify this down to
>>>>
>>>>
>>>>
>>>> - use PKCE
>>>>
>>>> - you may or may not use state
>>>>
>>>>
>>>>
>>>> First and foremost, not many people will understand why there are case=
s
>>>> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However=
,
>>>> understanding *why* you have to do something is key to compliance. The
>>>> short version "PKCE protects the code; there is a specific case where =
it is
>>>> not needed, but its better to use it all the time" is easy to understa=
nd.
>>>> We will not see many implementations following the long version above
>>>> correctly.
>>>>
>>>>
>>>>
>>>> Second, we dramatically reduce technical complexity by reducing cases
>>>> that need to be handled. We reduce correctness and compliance testing
>>>> complexity in the same way. We reduce the cost of security analysis, w=
hich
>>>> scales really badly to more cases.
>>>>
>>>>
>>>>
>>>> And finally, using nonce to protect against code injection is less
>>>> robust than PKCE. AS have a better track record than clients when it c=
omes
>>>> to correctly implementing security mechanisms.
>>>>
>>>>
>>>>
>>>> Yes, this will make a number of implementations non-spec-compliant, bu=
t
>>>> I do not think that this is a huge problem. Software needs to adapt al=
l the
>>>> time and a software that has not been changed in a while is probably n=
ot
>>>> one you would want to use anyway. We are setting a new goal for
>>>> implementations to meet and eventually, maintained implementations wil=
l get
>>>> there.
>>>>
>>>>
>>>>
>>>> -Daniel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>>>>
>>>> Backing up a step or two, there's another point here that I think has
>>>> been missed in these discussions.
>>>>
>>>>
>>>>
>>>> PKCE solves two problems: stolen authorization codes for public
>>>> clients, and authorization code injection for all clients. We've only =
been
>>>> talking about authorization code injection on the list so far. The quo=
ted
>>>> section of the security BCP (4.5.3) which says clients can do PKCE or =
use
>>>> the nonce, is only talking about preventing authorization code injecti=
on.
>>>>
>>>>
>>>>
>>>> The nonce parameter solves authorization code injection if the client
>>>> requests an ID token. Public clients using the nonce parameter are sti=
ll
>>>> susceptible to stolen authorization codes so they still need to do PKC=
E as
>>>> well.
>>>>
>>>>
>>>>
>>>> The only case where OpenID Connect clients don't benefit from PKCE is
>>>> if they are also confidential clients. Public client OIDC clients stil=
l
>>>> need to do PKCE even if they check the nonce.
>>>>
>>>>
>>>>
>>>> OpenID Connect servers working with confidential clients still benefit
>>>> from PKCE because they can then enforce the authorization code injecti=
on
>>>> protection server-side rather than cross their fingers that clients
>>>> implemented the nonce check properly.
>>>>
>>>>
>>>>
>>>> I really don't think it's worth the amount of explanation this will
>>>> take in the future to write an exception into OAuth 2.1 or the Securit=
y BCP
>>>> for only some types of OpenID Connect clients when all clients would
>>>> benefit from PKCE anyway.
>>>>
>>>>
>>>>
>>>> Aaron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt 
>>>> wrote:
>>>>
>>>> Hello!
>>>>
>>>>
>>>>
>>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>>>> best practice for OAuth 2.0. It is not common in OpenID Connect server=
s as
>>>> the nonce solves some of the issues that PKCE protects against. We thi=
nk
>>>> that most OpenID Connect implementations also support OAuth 2.0, and
>>>> hence have support for PKCE if following best practices.
>>>>
>>>>
>>>>
>>>> The advantages or requiring PKCE are:
>>>>
>>>>
>>>>
>>>> - a simpler programming model across all OAuth applications and
>>>> profiles as they all use PKCE
>>>>
>>>>
>>>>
>>>> - reduced attack surface when using  S256 as a fingerprint of the
>>>> verifier is sent through the browser instead of the clear text value
>>>>
>>>>
>>>>
>>>> - enforcement by AS not client - makes it easier to handle for client
>>>> developers and AS can ensure the check is conducted
>>>>
>>>>
>>>>
>>>> What are disadvantages besides the potential impact to OpenID Connect
>>>> deployments? How significant is that impact?
>>>>
>>>>
>>>>
>>>> Dick, Aaron, and Torsten
>>>>
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> OAuth@ietf.org
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> =E1=90=A7
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>> =E1=90=A7
>
>
> =E1=90=A7

--0000000000008c98e605a5548432
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It is a MUST to enforce consistency acros=
s all clients, and therefore to improve security for all clients.=C2=A0

An AS can decide to be OAuth 2.1 for all new clients,=
 and encourage existing clients to migrate to OAuth 2.1 (add support for PK=
CE).

If the client wants OAuth 2.1, the AS will en=
force it.

I don't follow your logic below=
 wrt. what an attacker will do.


On Sun, May =
10, 2020 at 1:46 PM Neil Madden <neil.madden@forgerock.com> wrote:
=

Let=E2=80=99s go back to basics. Why is this clause a MUST in the 2.1 =
spec? What does that accomplish?

It doesn=E2=80=99=
t provide any security benefit - an attacker can just as easily send a code=
_challenge as a legitimate client, there=E2=80=99s no secret involved. So e=
nforcing PKCE in this way doesn=E2=80=99t prevent any direct attacks. Presu=
mably then making it a hard fail is designed to drive adoption of PKCE - tu=
rning the thumbscrews on clients that otherwise wouldn=E2=80=99t bother?

But if we are saying that an AS can happily support =
legacy 2.0 clients without PKCE then the pressure of the MUST clause evapor=
ates and they are free to ignore it again. What=E2=80=99s the incentive for=
 an AS deployment to ever enforce 2.1 compliance if all it adds is a potent=
ial incompatibility with no security gain? (Given that servers and clients =
can already support PKCE if they wish).

All I can =
see this doing is delaying adoption of 2.1 by ASes.

=E2=80=94 Neil


On 10 May 2020, at 21:35, Dick Hardt <dick.hardt@gmail.com> wrote:

Sounds like your clients that have=
 set PKCE to be mandatory will then be OAuth 2.1 compliant with no extra wo=
rk.=C2=A0

A deployment can decide when they want to be c=
ompliant. That is not the specifications decision. I'm unclear on what =
point you are wanting to make below.=C2=A0


On Sun, May 1=
0, 2020 at 1:28 PM Neil Madden <neil.madden@forgerock.com> wrote:
This is the same as ha=
ving 2.1 compliance turned off by default. We already have a per-client set=
ting to make PKCE mandatory.

If you can turn it off, wha=
t=E2=80=99s the point of making it a MUST in the spec? What does an optiona=
l MUST even mean for an AS to claim 2.1 compliance?

=

On 10 May 2020, at 21:19, Dick Hardt &l=
t;dick.hardt@gmai=
l.com> wrote:

Is there a reason why a=
 server can not support both OAuth 2.0 and OAuth 2.1? The version supported=
 could be dependent=C2=A0on the client id, ie older clients could still be =
OAuth 2.0, and newer clients would be OAuth 2.1, and PKCE would be enforced=
.
3D"==E1=90=A7

On Sun, May 10, 2020 at 1:05 PM Nei=
l Madden <neil.madden@forgerock.com> wrote:
But if an AS upgrades to OAuth 2.1 then it M=
UST reject authorization requests that don=E2=80=99t include a code_challen=
ge (section 4.1.2.1), so this will only be possible when all clients suppor=
t PKCE.

This makes it impossible for a 2.1-compliant AS =
to also support non-PKCE 2.0 clients (i.e., the vast majority of them).
=


I think we can have a 2.1 spec that says clients a=
nd servers MUST support PKCE without this hard-fail clause. Otherwise I can=
=E2=80=99t see how we=E2=80=99d ever ship with 2.1-compliance enabled out-o=
f-the-box.

=E2=80=94 Neil

On 10 May 2020, at 20:38, Dick Hardt <dick.hardt@gmail.co=
m> wrote:

Hi Mike, I=
 would consider upgrading to OAuth 2.1 to be voluntary, just as the other e=
xtensions. Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0 was volu=
ntary.=C2=A0

Would you clarify why you think upgrading=
=C2=A0to OAuth 2.1 would be mandatory?


On Sun, May 10, =
2020 at 12:02 PM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org=
> wrote:









I agree with=
 actively maintaining and improving the OAuth 2.0 specs by adding enhanceme=
nts that are voluntary to use.=C2=A0 I=E2=80=99ve worked on many such impro=
vements, including Dynamic Client Registration, Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR, =
etc.=C2=A0 The issue that=E2=80=99s the subject is the current discussion i=
s whether to make use of another enhancement, PKCE, mandatory in cases wher=
e it=E2=80=99s actually not needed, rather than making
 its use voluntary like the other enhancements, which I certainly support.<=
u>
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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>
=C2=A0<=
u>


=
From: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org<=
/a>>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>


=C2=A0




Hi Mike,






=C2=A0




Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.i=
etf.org> schrieb am Fr. 8. Mai 2020 um 18:55:








OAuth 2.1 wa=
s supposed to not introduce breaking changes.=C2=A0







I cannot remember the WG met that decision. Can=
 you please refer to the respective thread?=C2=A0




=C2=A0




Requiring exact redirect URI matching is alread=
y a breaking change. Do you oppose against this as well?




=C2=A0




=C2=A0








If you want =
to do that, please do it in TxAuth instead.








=C2=A0




Interesting statement. Does it mean you want to=
 conserve OAuth 2.0 and force any enhancements/improvements to go into TXAu=
th? This would cause huge migration efforts for existing deployments wantin=
g to benefit from those enhancements.




=C2=A0




I think existing deployments are better served =
by actively maintaining and evolving the 2.x line. For example, PAR and RAR=
 are attempts to improve OAuth 2.x and make it usable for new use cases. Th=
at=E2=80=99s better protection of existing investments
 than sending them of to TXAuth.




Kind regards,




Torsten.




=C2=A0








=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0


+1 to all what Aaron said. Thanks for pointing =
this out!




=C2=A0




We need to address this in the security BCP and=
 this will be a normative change that affects OpenID Connect Core (just as =
our current recommendation on the usage of nonce).




=C2=A0




We would then have:




=C2=A0




- use PKCE, except if you use OIDC with a nonce=
, then you don't need PKCE, except if you are a public client, then you=
 still need PKCE.




- use state, except if you use PKCE, then you d=
on't need state.




=C2=A0




I think there are very good reasons to simplify=
 this down to





=C2=A0




- use PKCE




- you may or may not use state



=C2=A0




First and foremost, not many people will unders=
tand why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where=
 they don't. However, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.




=C2=A0




Second, we dramatically reduce technical comple=
xity by reducing cases that need to be handled. We reduce correctness and c=
ompliance testing complexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.=





=C2=A0




And finally, using nonce to protect against cod=
e injection is less robust than PKCE. AS have a better track record than cl=
ients when it comes to correctly implementing security
 mechanisms. 




=C2=A0




Yes, this will make a number of implementations=
 non-spec-compliant, but I do not think that this is a huge problem. Softwa=
re needs to adapt all the time and a software that has
 not been changed in a while is probably not one you would want to use anyw=
ay. We are setting a new goal for implementations to meet and eventually, m=
aintained implementations will get there.




=C2=A0




-Daniel




=C2=A0




=C2=A0




Am 08.05.20 um 01:38 schrieb Aaron Parecki:<=
/u>








Backing up a step or two, there's another p=
oint here that I think has been missed in these discussions.



=C2=A0




PKCE solves two problems: stolen authorization =
codes for public clients, and authorization code injection for all clients.=
 We've only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.




=C2=A0




The nonce parameter solves authorization code i=
njection if the client requests an ID token. Public clients using the nonce=
 parameter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.




=C2=A0




The only case where OpenID Connect clients don&=
#39;t benefit from PKCE is if they are also confidential clients. Public cl=
ient OIDC clients still need to do PKCE even if they check
 the nonce.




=C2=A0




OpenID Connect servers working with confidentia=
l clients still benefit from PKCE because they can then enforce the authori=
zation code injection protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.<=
/u>




=C2=A0




I really don't think it's worth the amo=
unt of explanation this will take in the future to write an exception into =
OAuth 2.1 or the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.




=C2=A0




Aaron




=C2=A0






=C2=A0


=C2=A0




On Wed, May 6, 2020 at 10:48 AM Dick Hardt <=
dick.hardt@gmail.=
com> wrote:








Hello!



=C2=A0




We would like to have PKCE be a MUST in OAuth 2=
.1 code flows. This is best practice for OAuth 2.0. It is not common in Ope=
nID Connect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.




=C2=A0




The advantages or requiring PKCE are:=





=C2=A0




- a simpler programming model across all OAuth =
applications and profiles as they all use PKCE




=C2=A0




- reduced attack surface when using=C2=A0 S256 =
as a fingerprint of the verifier is sent through the browser instead of the=
 clear text value




=C2=A0




- enforcement by AS not client - makes it easie=
r to handle for client developers and AS can ensure the check is conducted<=
u>




=C2=A0




What are disadvantages besides the potential im=
pact to OpenID Connect deployments? How significant is that impact?<=
u>




=C2=A0




Dick, Aaron, and Torsten




=C2=A0








=E1=90=A7








=C2=A0<=
/u>


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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


=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


3D""=E1=90=A7

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



3D""=E1=90=A7


3D""=E1=90=
=A7


--0000000000008c98e605a5548432--


From nobody Sun May 10 22:31:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8033A07CB for ; Sun, 10 May 2020 22:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t4hCCuNk2E8 for ; Sun, 10 May 2020 22:31:06 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64183A07C8 for ; Sun, 10 May 2020 22:31:05 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04B5V1B9017525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 11 May 2020 01:31:03 -0400
Date: Sun, 10 May 2020 22:31:01 -0700
From: Benjamin Kaduk 
To: oauth@ietf.org
Message-ID: <20200511053101.GJ27494@kduck.mit.edu>
References:   <3b016c63-facd-a1cf-cb58-6ad5d8633055@danielfett.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3b016c63-facd-a1cf-cb58-6ad5d8633055@danielfett.de>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 05:31:09 -0000

My apologies for a tangent on an already-long thread...

On Fri, May 08, 2020 at 08:50:16AM +0200, Daniel Fett wrote:
> 
> Yes, this will make a number of implementations non-spec-compliant, but
> I do not think that this is a huge problem. Software needs to adapt all
> the time and a software that has not been changed in a while is probably
> not one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will
> get there.

It's probably worth an occasional reminder that though this is true for the
web-facing software most of us work on, it's not actually universally true
for *all* software.  Things that are rated as safety-critical software, or
the SCADA systems running billion-dollar industrial processes that only
take downtime for hardware upgrades, are written in a rather different
ecosystem.  :)

-Ben


From nobody Sun May 10 22:38:37 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FD23A07D8 for ; Sun, 10 May 2020 22:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf-lOL6Dmw8y for ; Sun, 10 May 2020 22:38:31 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBE13A07CE for ; Sun, 10 May 2020 22:38:31 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id n5so2737253wmd.0 for ; Sun, 10 May 2020 22:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Z+KYt1WwoVT7melOJdjFV/mCETPu8XxWyDgm0mmFMKs=; b=A2/EiIWyW2WhEPXVhCXtEpunGM1cld9MgSiIFOJu6QIswyaMAJSId0EFL4tjvbPHec 0UZxBzIexzLsiffb3QGnH+aMeHrrfiF7mqEfZNyLv0zcab9b3lFh1Q00yC8UPpidZgIs x5Y9BYcQliuxGPmtKVr686suJL9P7fOdEKXcs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Z+KYt1WwoVT7melOJdjFV/mCETPu8XxWyDgm0mmFMKs=; b=VJy9b2x3zYx44Z9CaK+JrsmOqVwGAfdi4BEsYkK7k5LU4g/tefiPh0Uxvj4IQYO7cP KFj+/dNv3t5hFlacf11kxKhwxlydwln5WszBCl28woWTUHr/deF7oSMdX41SS/q1MdsN 6WWj+q1rNtZPTA9OPPtThKqVD7wEe3zeEYhSCkYJTuVD52isTADOkYyVlgku9oz6Lo0T KPGXiXfTgszboPf92O6y9mLDqdzw3Ur87qMIOVzXKhdss4llyIHUbe5XPhW+EUXYSFQK 1c81Faah2yZ7P5Wa60BPULnaTleTfuJ4J53aTkl8umj9QGsFCqpvAU86LcdzK0kbVJqy gnZg==
X-Gm-Message-State: AGi0Pub4jHKTULGosMtaEdDl5o/PCzxQ9iz5U2sFTwmMRQ/P2IJ2HOaq WMQl3J4qMkWX1f1c+STVYYn7FA==
X-Google-Smtp-Source: APiQypKxzaMVUcHUW/81aN+PVaDCRA7H+HSM6Fw5yzgg8M192mrm4MQuXgtqlh5zMVRhSQDizZu3nQ==
X-Received: by 2002:a1c:1d41:: with SMTP id d62mr8875581wmd.79.1589175509328;  Sun, 10 May 2020 22:38:29 -0700 (PDT)
Received: from [10.0.0.3] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id y63sm25956620wmg.21.2020.05.10.22.38.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 22:38:28 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-F775AE5B-80F9-422D-A0D2-FB8FA74F9961
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Mon, 11 May 2020 06:38:27 +0100
Message-Id: <5E226F17-E2A9-4050-86F1-19483D3343E7@forgerock.com>
References: 
Cc: Mike Jones , "oauth@ietf.org" , Torsten Lodderstedt 
In-Reply-To: 
To: Dick Hardt 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 05:38:35 -0000

--Apple-Mail-F775AE5B-80F9-422D-A0D2-FB8FA74F9961
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

There is no attack that this prevents so your claim of improving security is=
 unsubstantiated. I can=E2=80=99t see how we can ship a 2.1-compliant-by-def=
ault AS while this requirement remains so I don=E2=80=99t support it.=20

Neil

> On 11 May 2020, at 01:35, Dick Hardt  wrote:
>=20
> =EF=BB=BF
> It is a MUST to enforce consistency across all clients, and therefore to i=
mprove security for all clients.=20
>=20
> An AS can decide to be OAuth 2.1 for all new clients, and encourage existi=
ng clients to migrate to OAuth 2.1 (add support for PKCE).
>=20
> If the client wants OAuth 2.1, the AS will enforce it.
>=20
> I don't follow your logic below wrt. what an attacker will do.
>=20
>=20
>> On Sun, May 10, 2020 at 1:46 PM Neil Madden  w=
rote:
>> Let=E2=80=99s go back to basics. Why is this clause a MUST in the 2.1 spe=
c? What does that accomplish?
>>=20
>> It doesn=E2=80=99t provide any security benefit - an attacker can just as=
 easily send a code_challenge as a legitimate client, there=E2=80=99s no sec=
ret involved. So enforcing PKCE in this way doesn=E2=80=99t prevent any dire=
ct attacks. Presumably then making it a hard fail is designed to drive adopt=
ion of PKCE - turning the thumbscrews on clients that otherwise wouldn=E2=80=
=99t bother?
>>=20
>> But if we are saying that an AS can happily support legacy 2.0 clients wi=
thout PKCE then the pressure of the MUST clause evaporates and they are free=
 to ignore it again. What=E2=80=99s the incentive for an AS deployment to ev=
er enforce 2.1 compliance if all it adds is a potential incompatibility with=
 no security gain? (Given that servers and clients can already support PKCE i=
f they wish).
>>=20
>> All I can see this doing is delaying adoption of 2.1 by ASes.
>>=20
>> =E2=80=94 Neil
>>=20
>>=20
>>> On 10 May 2020, at 21:35, Dick Hardt  wrote:
>>>=20
>>> Sounds like your clients that have set PKCE to be mandatory will then be=
 OAuth 2.1 compliant with no extra work.=20
>>>=20
>>> A deployment can decide when they want to be compliant. That is not the s=
pecifications decision. I'm unclear on what point you are wanting to make be=
low.=20
>>>=20
>>>=20
>>>> On Sun, May 10, 2020 at 1:28 PM Neil Madden =
 wrote:
>>>> This is the same as having 2.1 compliance turned off by default. We alr=
eady have a per-client setting to make PKCE mandatory.
>>>>=20
>>>> If you can turn it off, what=E2=80=99s the point of making it a MUST in=
 the spec? What does an optional MUST even mean for an AS to claim 2.1 compl=
iance?
>>>>=20
>>>>> On 10 May 2020, at 21:19, Dick Hardt  wrote:
>>>>>=20
>>>>> Is there a reason why a server can not support both OAuth 2.0 and OAut=
h 2.1? The version supported could be dependent on the client id, ie older c=
lients could still be OAuth 2.0, and newer clients would be OAuth 2.1, and P=
KCE would be enforced.
>>>>> =E1=90=A7
>>>>>=20
>>>>>> On Sun, May 10, 2020 at 1:05 PM Neil Madden  wrote:
>>>>>> But if an AS upgrades to OAuth 2.1 then it MUST reject authorization r=
equests that don=E2=80=99t include a code_challenge (section 4.1.2.1), so th=
is will only be possible when all clients support PKCE.
>>>>>>=20
>>>>>> This makes it impossible for a 2.1-compliant AS to also support non-P=
KCE 2.0 clients (i.e., the vast majority of them).
>>>>>>=20
>>>>>> I think we can have a 2.1 spec that says clients and servers MUST sup=
port PKCE without this hard-fail clause. Otherwise I can=E2=80=99t see how w=
e=E2=80=99d ever ship with 2.1-compliance enabled out-of-the-box.
>>>>>>=20
>>>>>> =E2=80=94 Neil
>>>>>>=20
>>>>>>> On 10 May 2020, at 20:38, Dick Hardt  wrote:
>>>>>>>=20
>>>>>>> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, ju=
st as the other extensions. Similarly, OAuth 1.0 deployments upgrading to OA=
uth 2.0 was voluntary.=20
>>>>>>>=20
>>>>>>> Would you clarify why you think upgrading to OAuth 2.1 would be mand=
atory?
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Sun, May 10, 2020 at 12:02 PM Mike Jones  wrote:
>>>>>>>> I agree with actively maintaining and improving the OAuth 2.0 specs=
 by adding enhancements that are voluntary to use.  I=E2=80=99ve worked on m=
any such improvements, including Dynamic Client Registration, Authorization M=
etadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR, etc=
.  The issue that=E2=80=99s the subject is the current discussion is whether=
 to make use of another enhancement, PKCE, mandatory in cases where it=E2=80=
=99s actually not needed, rather than making its use voluntary like the othe=
r enhancements, which I certainly support.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>>                                                        -- Mike
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> From: Torsten Lodderstedt =20
>>>>>>>> Sent: Sunday, May 10, 2020 3:15 AM
>>>>>>>> To: Mike Jones 
>>>>>>>> Cc: Daniel Fett ; oauth@ietf.org
>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Hi Mike,
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Mike Jones  schrieb=
 am Fr. 8. Mai 2020 um 18:55:
>>>>>>>>=20
>>>>>>>> OAuth 2.1 was supposed to not introduce breaking changes.=20
>>>>>>>>=20
>>>>>>>> I cannot remember the WG met that decision. Can you please refer to=
 the respective thread?=20
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Requiring exact redirect URI matching is already a breaking change.=
 Do you oppose against this as well?
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> If you want to do that, please do it in TxAuth instead.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Interesting statement. Does it mean you want to conserve OAuth 2.0 a=
nd force any enhancements/improvements to go into TXAuth? This would cause h=
uge migration efforts for existing deployments wanting to benefit from those=
 enhancements.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> I think existing deployments are better served by actively maintain=
ing and evolving the 2.x line. For example, PAR and RAR are attempts to impr=
ove OAuth 2.x and make it usable for new use cases. That=E2=80=99s better pr=
otection of existing investments than sending them of to TXAuth.
>>>>>>>>=20
>>>>>>>> Kind regards,
>>>>>>>>=20
>>>>>>>> Torsten.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>>                                                        -- Mike
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> From: OAuth  On Behalf Of Daniel Fett
>>>>>>>> Sent: Thursday, May 7, 2020 11:50 PM
>>>>>>>> To: oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> +1 to all what Aaron said. Thanks for pointing this out!
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> We need to address this in the security BCP and this will be a norm=
ative change that affects OpenID Connect Core (just as our current recommend=
ation on the usage of nonce).
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> We would then have:
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> - use PKCE, except if you use OIDC with a nonce, then you don't nee=
d PKCE, except if you are a public client, then you still need PKCE.
>>>>>>>>=20
>>>>>>>> - use state, except if you use PKCE, then you don't need state.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> I think there are very good reasons to simplify this down to
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> - use PKCE
>>>>>>>>=20
>>>>>>>> - you may or may not use state
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> First and foremost, not many people will understand why there are c=
ases when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,=
 understanding why you have to do something is key to compliance. The short v=
ersion "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We will n=
ot see many implementations following the long version above correctly.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Second, we dramatically reduce technical complexity by reducing cas=
es that need to be handled. We reduce correctness and compliance testing com=
plexity in the same way. We reduce the cost of security analysis, which scal=
es really badly to more cases.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> And finally, using nonce to protect against code injection is less r=
obust than PKCE. AS have a better track record than clients when it comes to=
 correctly implementing security mechanisms.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Yes, this will make a number of implementations non-spec-compliant,=
 but I do not think that this is a huge problem. Software needs to adapt all=
 the time and a software that has not been changed in a while is probably no=
t one you would want to use anyway. We are setting a new goal for implementa=
tions to meet and eventually, maintained implementations will get there.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> -Daniel
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>>>>>>>>=20
>>>>>>>> Backing up a step or two, there's another point here that I think h=
as been missed in these discussions.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> PKCE solves two problems: stolen authorization codes for public cli=
ents, and authorization code injection for all clients. We've only been talk=
ing about authorization code injection on the list so far. The quoted sectio=
n of the security BCP (4.5.3) which says clients can do PKCE or use the nonc=
e, is only talking about preventing authorization code injection.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> The nonce parameter solves authorization code injection if the clie=
nt requests an ID token. Public clients using the nonce parameter are still s=
usceptible to stolen authorization codes so they still need to do PKCE as we=
ll.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> The only case where OpenID Connect clients don't benefit from PKCE i=
s if they are also confidential clients. Public client OIDC clients still ne=
ed to do PKCE even if they check the nonce.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> OpenID Connect servers working with confidential clients still bene=
fit from PKCE because they can then enforce the authorization code injection=
 protection server-side rather than cross their fingers that clients impleme=
nted the nonce check properly.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> I really don't think it's worth the amount of explanation this will=
 take in the future to write an exception into OAuth 2.1 or the Security BCP=
 for only some types of OpenID Connect clients when all clients would benefi=
t from PKCE anyway.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Aaron
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  w=
rote:
>>>>>>>>=20
>>>>>>>> Hello!
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This i=
s best practice for OAuth 2.0. It is not common in OpenID Connect servers as=
 the nonce solves some of the issues that PKCE protects against. We think th=
at most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e support for PKCE if following best practices.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> The advantages or requiring PKCE are:
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> - a simpler programming model across all OAuth applications and pro=
files as they all use PKCE
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> - reduced attack surface when using  S256 as a fingerprint of the v=
erifier is sent through the browser instead of the clear text value
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> - enforcement by AS not client - makes it easier to handle for clie=
nt developers and AS can ensure the check is conducted
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> What are disadvantages besides the potential impact to OpenID Conne=
ct deployments? How significant is that impact?
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> Dick, Aaron, and Torsten
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> =E1=90=A7
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> =20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>> =E1=90=A7
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>=20
>>>=20
>>> =E1=90=A7
>>=20
>=20
> =E1=90=A7

--Apple-Mail-F775AE5B-80F9-422D-A0D2-FB8FA74F9961
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


There is no attack that th=
is prevents so your claim of improving security is unsubstantiated. I can=E2=
=80=99t see how we can ship a 2.1-compliant-by-default AS while this require=
ment remains so I don=E2=80=99t support it. 

=

Neil

On 11 May 2020, at 01:35, Dick Hardt <dick.hardt@gmail.com> wrote:=


=EF=BB=
=BF
It is a MUST to enforce consistency acr=
oss all clients, and therefore to improve security for all clients. 

An AS can decide to be OAuth 2.1 for all new clients,=
 and encourage existing clients to migrate to OAuth 2.1 (add support for PKC=
E).

If the client wants OAuth 2.1, the AS will enfo=
rce it.

I don't follow your logic below wrt. w=
hat an attacker will do.


On Sun, May 10, 2020 a=
t 1:46 PM Neil Madden <neil.=
madden@forgerock.com> wrote:
Let=E2=80=99=
s go back to basics. Why is this clause a MUST in the 2.1 spec? What does th=
at accomplish?

It doesn=E2=80=99t provide any secur=
ity benefit - an attacker can just as easily send a code_challenge as a legi=
timate client, there=E2=80=99s no secret involved. So enforcing PKCE in this=
 way doesn=E2=80=99t prevent any direct attacks. Presumably then making it a=
 hard fail is designed to drive adoption of PKCE - turning the thumbscrews o=
n clients that otherwise wouldn=E2=80=99t bother?

B=
ut if we are saying that an AS can happily support legacy 2.0 clients withou=
t PKCE then the pressure of the MUST clause evaporates and they are free to i=
gnore it again. What=E2=80=99s the incentive for an AS deployment to ever en=
force 2.1 compliance if all it adds is a potential incompatibility with no s=
ecurity gain? (Given that servers and clients can already support PKCE if th=
ey wish).

All I can see this doing is delaying adop=
tion of 2.1 by ASes.

=E2=80=94 Neil

<=
/div>

On 10 May 2020, at 21:35, Dick H=
ardt <dick.hard=
t@gmail.com> wrote:

<=
/div>Sounds like your clients that have set PKCE to be mandatory will then b=
e OAuth 2.1 compliant with no extra work. 

A deploym=
ent can decide when they want to be compliant. That is not the specification=
s decision. I'm unclear on what point you are wanting to make below. 


On Sun, May 10, 2020 at 1:28 PM Neil Madden <neil.madden@forgerock.co=
m> wrote:
<=
div>This is the same as having 2.1 compliance turned off by default. We alre=
ady have a per-client setting to make PKCE mandatory.

If y=
ou can turn it off, what=E2=80=99s the point of making it a MUST in the spec=
? What does an optional MUST even mean for an AS to claim 2.1 compliance?

On 10 May 2020, at 2=
1:19, Dick Hardt <dick.hardt@gmail.com> wrote:

Is the=
re a reason why a server can not support both OAuth 2.0 and OAuth 2.1? The v=
ersion supported could be dependent on the client id, ie older clients c=
ould still be OAuth 2.0, and newer clients would be OAuth 2.1, and PKCE woul=
d be enforced.
=
3D""=E1=90=A7
On S=
un, May 10, 2020 at 1:05 PM Neil Madden <neil.madden@forgerock.com> wrote:
<=
/div>
But if an AS upgr=
ades to OAuth 2.1 then it MUST reject authorization requests that don=E2=80=99=
t include a code_challenge (section 4.1.2.1), so this will only be possible w=
hen all clients support PKCE.

This makes it impossible fo=
r a 2.1-compliant AS to also support non-PKCE 2.0 clients (i.e., the vast ma=
jority of them).

I think we can have a 2.1 spec t=
hat says clients and servers MUST support PKCE without this hard-fail clause=
. Otherwise I can=E2=80=99t see how we=E2=80=99d ever ship with 2.1-complian=
ce enabled out-of-the-box.

=E2=80=94 Neil

On 10 May 2020, at 20:38, Dic=
k Hardt <dick.h=
ardt@gmail.com> wrote:

Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as t=
he other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0=
 was voluntary. 

Would you clarify why you think upg=
rading to OAuth 2.1 would be mandatory?


<=
div class=3D"gmail_quote">
On Sun, May 1=
0, 2020 at 12:02 PM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:









I agree with a=
ctively maintaining and improving the OAuth 2.0 specs by adding enhancements=
 that are voluntary to use.  I=E2=80=99ve worked on many such improveme=
nts, including Dynamic Client Registration, Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR, e=
tc.  The issue that=E2=80=99s the subject is the current discussion is w=
hether to make use of another enhancement, PKCE, mandatory in cases where it=
=E2=80=99s actually not needed, rather than making
 its use voluntary like the other enhancements, which I certainly support.
 
         &nbs=
p;            &n=
bsp;            =
            &nbs=
p;       -- Mike
 


From: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org&=
gt;


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?


 




Hi Mike,






 




Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.iet=
f.org> schrieb am Fr. 8. Mai 2020 um 18:55:








OAuth 2.1 was=
 supposed to not introduce breaking changes. 








I cannot remember the WG met that decision. Can y=
ou please refer to the respective thread? 




 




Requiring exact redirect URI matching is already=
 a breaking change. Do you oppose against this as well?




 




 








If you want t=
o do that, please do it in TxAuth instead.








 




Interesting statement. Does it mean you want to c=
onserve OAuth 2.0 and force any enhancements/improvements to go into TXAuth?=
 This would cause huge migration efforts for existing deployments wanting to=
 benefit from those enhancements.




 




I think existing deployments are better served b=
y actively maintaining and evolving the 2.x line. For example, PAR and RAR a=
re attempts to improve OAuth 2.x and make it usable for new use cases. That=E2=
=80=99s better protection of existing investments
 than sending them of to TXAuth.




Kind regards,




Torsten.




 








 =

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




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.or=
g

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




 


+1 to all what Aaron said. Thanks for pointing t=
his out!




 




We need to address this in the security BCP and t=
his will be a normative change that affects OpenID Connect Core (just as our=
 current recommendation on the usage of nonce).




 




We would then have:




 




- use PKCE, except if you use OIDC with a nonce,=
 then you don't need PKCE, except if you are a public client, then you still=
 need PKCE.




- use state, except if you use PKCE, then you do=
n't need state.




 




I think there are very good reasons to simplify t=
his down to





 




- use PKCE




- you may or may not use state
=




 




First and foremost, not many people will underst=
and why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where t=
hey don't. However, understanding
why you have to do something is key to compliance. The short version "=
PKCE protects the code; there is a specific case where it is not needed, but=
 its better to use it all the time" is easy to understand. We will not see m=
any implementations following
 the long version above correctly.




 




Second, we dramatically reduce technical complex=
ity by reducing cases that need to be handled. We reduce correctness and com=
pliance testing complexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.<=
/u>




 




And finally, using nonce to protect against code=
 injection is less robust than PKCE. AS have a better track record than clie=
nts when it comes to correctly implementing security
 mechanisms. 




 




Yes, this will make a number of implementations n=
on-spec-compliant, but I do not think that this is a huge problem. Software n=
eeds to adapt all the time and a software that has
 not been changed in a while is probably not one you would want to use anywa=
y. We are setting a new goal for implementations to meet and eventually, mai=
ntained implementations will get there.




 




-Daniel




 




 




Am 08.05.20 um 01:38 schrieb Aaron Parecki:








Backing up a step or two, there's another point h=
ere that I think has been missed in these discussions.



 




PKCE solves two problems: stolen authorization c=
odes for public clients, and authorization code injection for all clients. W=
e've only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which sa=
ys clients can do PKCE or use the nonce, is only talking about preventing au=
thorization code injection.




 




The nonce parameter solves authorization code in=
jection if the client requests an ID token. Public clients using the nonce p=
arameter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.




 




The only case where OpenID Connect clients don't=
 benefit from PKCE is if they are also confidential clients. Public client O=
IDC clients still need to do PKCE even if they check
 the nonce.




 




OpenID Connect servers working with confidential=
 clients still benefit from PKCE because they can then enforce the authoriza=
tion code injection protection server-side rather than
 cross their fingers that clients implemented the nonce check properly.




 




I really don't think it's worth the amount of ex=
planation this will take in the future to write an exception into OAuth 2.1 o=
r the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.




 




Aaron




 






 


 




On Wed, May 6, 2020 at 10:48 AM Dick Hardt <<=
a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.co=
m> wrote:








Hello!



 




We would like to have PKCE be a MUST in OAuth 2.=
1 code flows. This is best practice for OAuth 2.0. It is not common in OpenI=
D Connect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementatio=
ns also support OAuth 2.0, and hence have support for PKCE if following=
 best practices.




 




The advantages or requiring PKCE are:<=
/u>




 




- a simpler programming model across all OAuth a=
pplications and profiles as they all use PKCE




 




- reduced attack surface when using  S256 a=
s a fingerprint of the verifier is sent through the browser instead of the c=
lear text value




 




- enforcement by AS not client - makes it easier=
 to handle for client developers and AS can ensure the check is conducted=





 




What are disadvantages besides the potential imp=
act to OpenID Connect deployments? How significant is that impact?=





 




Dick, Aaron, and Torsten




 








=E1=90=A7
=








 


_______________________________________________


OAuth mailing list


OAuth@ietf.org<=
u>


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/mailman/listinfo/oauth


3D""=E1=90=A7

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




3D""=E1=90=A7



3D""=E1=90=A7

=

--Apple-Mail-F775AE5B-80F9-422D-A0D2-FB8FA74F9961--


From nobody Sun May 10 23:40:51 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F7F3A084B for ; Sun, 10 May 2020 23:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOi2dnGs020C for ; Sun, 10 May 2020 23:40:43 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CB13A0837 for ; Sun, 10 May 2020 23:40:41 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id y3so9390392wrt.1 for ; Sun, 10 May 2020 23:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j2szNaOl+asOian+b8zZ7R/1NCprJtkB4qLOegO9/PU=; b=biwwWJWfLIvJD0Ny48mjI5aTqesdFfnd+4TdmAnymLXWGaoelXbg/lN/iFiwrCJV2q j5TrRY/anNfKhDrS93DHr3nrTRHPHN1BuycNm2rz6/WVIN814oBmDVz2xYdKJFgktcv0 jxzCxCxoMGehGq/c1w9z9nQ6DTlLGuRxP/xjXsduauG1qWt+4DzaNqaK114NKFPAxXb0 L/HF7yqGsUNst7o5ilWn5RJENfsthKLGc2FuSn9zWWbx1lQuONd9SPiH8mJYHDk0vT6t MJrpDM7A5sNTp1uLGD1QbiNvWkaFx8r1iiPx0r0geFUWlBxtoMWrf06lTdXvNQ/2B6Ry FF5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j2szNaOl+asOian+b8zZ7R/1NCprJtkB4qLOegO9/PU=; b=n6zXFDvlEUWqhlLk5hvjFdmaEDBdw0zak1T3vwpaHYds0pzrg+unUINsG2IJTKb4W/ 86qzvMqL9oP+J2RABP6+1u4zWJkS9x8XwlYxFNGMEu+ImOPqAwgp9VHFg3ftfCWHQpyZ 468WM5V0K6PhmINRhU0PiZY9eqQZd9HvTaaVtTMyNrCOHYfuKjaycAJbAdAX5Vzf0Qen k0OhUKH+6VoYsz4JVk1U+3Iwhe3RvlU2UURxcAhlSEVw5Wc7GGDDSdZp7vb5C6e8FUbJ cLkRBpp+b+yi5SmXy9wDCwpRpUaxUT9JTiy8itjZWuFCvaFFJlzNFVAAO+0kcsQCeU7K Pc3A==
X-Gm-Message-State: AGi0Pub2dw6eKvOshj8LjQCMd/yqdZw7xGitVthxWYOhiA711npQ31iy rTtRpJ+15ExxbIokJMjRXmMwGA==
X-Google-Smtp-Source: APiQypLzQzBgPTkOQzNuikTNpVby3lyusXCQGWf+Hj6UJPO/N8bHOhawrDHDIoVOltRCqbk6G8yFfQ==
X-Received: by 2002:a5d:614b:: with SMTP id y11mr18062123wrt.77.1589179239624;  Sun, 10 May 2020 23:40:39 -0700 (PDT)
Received: from p200300eb8f301f67a4ec9c1a06d87114.dip0.t-ipconnect.de (p200300EB8F301F67A4EC9C1A06D87114.dip0.t-ipconnect.de. [2003:eb:8f30:1f67:a4ec:9c1a:6d8:7114]) by smtp.gmail.com with ESMTPSA id r11sm13248067wma.35.2020.05.10.23.40.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2020 23:40:39 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Mon, 11 May 2020 08:40:35 +0200
Cc: Aaron Parecki , Dick Hardt , OAuth WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <81A18E7D-44BB-4BE1-B93F-6584FC6DA862@lodderstedt.net>
References: 
To: Mike Jones 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 06:40:49 -0000

> On 10. May 2020, at 21:02, Mike Jones  =
wrote:
>=20
> > Did I got it right that nonce does not protect public clients from =
code theft/replay?
> =20
> I believe that the OpenID Connect Code Hash (=E2=80=9Cc_hash=E2=80=9D) =
claim protects against this. =20

c_hash is designed to prevent injection at a legit client and must be =
enforced by the client - just like nonce.=20

That might work with a confidential client, but in case of a public =
client, the attacker does not need to inject the code in order to redeem =
it. The attacker can just directly redeem the code for an access token =
without checking c_hash or nonce.

> I=E2=80=99d be interested in hearing John Bradley=E2=80=99s take on =
this.
> =20
>                                                        -- Mike
> =20
> From: Torsten Lodderstedt =20
> Sent: Sunday, May 10, 2020 3:17 AM
> To: Mike Jones 
> Cc: Aaron Parecki ; Dick Hardt =
; OAuth WG 
> Subject: Re: OAuth 2.1 - require PKCE?
> =20
> Mike Jones  schrieb am Sa. 9. Mai 2020 um =
20:46:
> There=E2=80=99s a huge ecosystem of successful, secure OAuth 2.0 and =
OpenID Connect deployments that we have the responsibility to be =
stewards of.  This working group should be proud of what it=E2=80=99s =
accomplished.  Part of good stewardship is not unnecessarily bifurcating =
the ecosystem into non-interoperable segments.  OAuth 2.1 should =
facilitate the already secure OAuth 2.0 deployments remaining part of =
the interoperable OAuth 2.1 set of deployments =E2=80=93 not =
intentionally doing the opposite.
> =20
> If it ain=E2=80=99t broke, don=E2=80=99t fix it!
> Did I got it right that nonce does not protect public clients from =
code theft/replay? I would consider this a security issue.
> =20
>                                                        -- Mike
> =20
> From: Aaron Parecki =20
> Sent: Friday, May 8, 2020 8:34 PM
> To: OAuth WG 
> Cc: Dick Hardt ; Torsten Lodderstedt =
; Mike Jones 
> Subject: Re: OAuth 2.1 - require PKCE?
> =20
> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  =
You=E2=80=99re concerned about =E2=80=9Cthe amount of explanation this =
will take=E2=80=9D.  That=E2=80=99s optimizing for spec simplicity =E2=80=93=
 a goal that I do understand.  However, by writing these few sentences =
or paragraphs, we=E2=80=99ll make it clear to developers that hundreds =
or thousands of deployed OpenID Connect RPs won=E2=80=99t have to change =
their deployments.  That=E2=80=99s optimizing for interoperability and =
minimizing the burden on developers, which are far more important.
> =20
> I appreciate the concern about optimizing for spec simplicity. I also =
agree that spec simplicity should not necessarily be the driving goal.
> =20
> However, what you've described is the opposite of interoperability and =
minimizing the burden on developers. Requiring PKCE in OAuth 2.1, =
without any exceptions, will optimize for interoperability between OAuth =
2.1 clients and servers. Without the requirement of PKCE, there will =
always be the question of "but does this OAuth 2.1 client work with this =
OAuth 2.1 server or not?", which will only be able to be answered by =
investigating the docs to look for PKCE support, or by checking the AS =
metadata document if it publishes one (which it is not required to do).
> =20
> Optimizing for interoperability and minimizing the burden on =
developers is absolutely a good goal, and requiring PKCE is a great way =
to accomplish that. OAuth 2.0 and OpenID Connect implementations that =
don't support PKCE will continue to work as they currently do, they just =
won't be able to call themselves OAuth 2.1 compliant, just as is the =
case as if they don't follow the other recommendations that are in OAuth =
2.1 and the Security BCP.
> =20
> Aaron=20
> =20
> =20
> On Thu, May 7, 2020 at 6:42 PM Mike Jones =
 wrote:
> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  =
You=E2=80=99re concerned about =E2=80=9Cthe amount of explanation this =
will take=E2=80=9D.  That=E2=80=99s optimizing for spec simplicity =E2=80=93=
 a goal that I do understand.  However, by writing these few sentences =
or paragraphs, we=E2=80=99ll make it clear to developers that hundreds =
or thousands of deployed OpenID Connect RPs won=E2=80=99t have to change =
their deployments.  That=E2=80=99s optimizing for interoperability and =
minimizing the burden on developers, which are far more important.
> =20
> As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have =
very different ramifications on interoperability=E2=80=9D.
> =20
> Even if you=E2=80=99re optimizing for writing, taking a minimally =
invasive protocol change approach will optimize that, overall.  If we =
proceed as you=E2=80=99re suggesting, a huge amount of writing will =
occur on StackOverflow, Medium, SlashDot, blogs, and other developer =
forums, where confused developers will ask =E2=80=9CWhy do I have to =
change my deployed code?=E2=80=9D with the answers being =E2=80=9CDespite =
what the 2.1 spec says, there=E2=80=99s no need to change your deployed =
code.=E2=80=9D
> =20
> I=E2=80=99d gladly write a few sentences in our new specs now to =
prevent ongoing confusion and interop problems that would otherwise =
result.  Let me know when you=E2=80=99re ready to incorporate them into =
the spec text.
> =20
>                                                        -- Mike
> =20
> From: Aaron Parecki =20
> Sent: Thursday, May 7, 2020 4:39 PM
> To: Dick Hardt 
> Cc: OAuth WG ; Torsten Lodderstedt =
; Mike Jones 
> Subject: Re: OAuth 2.1 - require PKCE?
> =20
> Backing up a step or two, there's another point here that I think has =
been missed in these discussions.
> =20
> PKCE solves two problems: stolen authorization codes for public =
clients, and authorization code injection for all clients. We've only =
been talking about authorization code injection on the list so far. The =
quoted section of the security BCP (4.5.3) which says clients can do =
PKCE or use the nonce, is only talking about preventing authorization =
code injection.
> =20
> The nonce parameter solves authorization code injection if the client =
requests an ID token. Public clients using the nonce parameter are still =
susceptible to stolen authorization codes so they still need to do PKCE =
as well.
> =20
> The only case where OpenID Connect clients don't benefit from PKCE is =
if they are also confidential clients. Public client OIDC clients still =
need to do PKCE even if they check the nonce.
> =20
> OpenID Connect servers working with confidential clients still benefit =
from PKCE because they can then enforce the authorization code injection =
protection server-side rather than cross their fingers that clients =
implemented the nonce check properly.
> =20
> I really don't think it's worth the amount of explanation this will =
take in the future to write an exception into OAuth 2.1 or the Security =
BCP for only some types of OpenID Connect clients when all clients would =
benefit from PKCE anyway.
> =20
> Aaron
> =20
> =20
> =20
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  =
wrote:
> Hello!
> =20
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is =
best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as the nonce solves some of the issues that PKCE protects against. We =
think that most OpenID Connect implementations also support OAuth 2.0, =
and hence have support for PKCE if following best practices.
> =20
> The advantages or requiring PKCE are:
> =20
> - a simpler programming model across all OAuth applications and =
profiles as they all use PKCE
> =20
> - reduced attack surface when using  S256 as a fingerprint of the =
verifier is sent through the browser instead of the clear text value
> =20
> - enforcement by AS not client - makes it easier to handle for client =
developers and AS can ensure the check is conducted
> =20
> What are disadvantages besides the potential impact to OpenID Connect =
deployments? How significant is that impact?
> =20
> Dick, Aaron, and Torsten
> =20
> =E1=90=A7


From nobody Sun May 10 23:41:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9223C3A0885 for ; Sun, 10 May 2020 23:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68EXjXcQyLxf for ; Sun, 10 May 2020 23:41:04 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0573A086E for ; Sun, 10 May 2020 23:41:04 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id f134so4580311wmf.1 for ; Sun, 10 May 2020 23:41:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xoL/kTr4HWnJ4ifL0INWqQb6UN7bU06j/1f9OEP73nM=; b=lXTShAyBRmiqZgUPl+PoR1ZwYKs+vwhs1/gdEpipvYG91UuE2UX42WGd3o+x3vRhlv bfLpk1UZx1OJWVZ+PHrAyBGm2kdW6HfshoX60vgbH+RwiUHIWbCTEWzbwyjEt0ookVKu lt1ovBCIQj8UL+AIcdF9ctjfN+Eqer+vsP3iDUL4BZ5f97DDMRZM+f+d6OlLBFBxaY5z 9N23DP61sjKJqVjQTgov5ZSHXXTZ6bGi89Z5O1drdZSIT0eARzPUYumqykO53QTsc1+E 0lB9NlAmTVwHhfixoYR9F9MwOc42sIBGn+wPD7qCGZRq7gWZdD1HD8l7H3TmjLdt0sAb gItQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xoL/kTr4HWnJ4ifL0INWqQb6UN7bU06j/1f9OEP73nM=; b=kU8rGOjz7QYWuYSwHF89ZM+z2Lz6G95mReXLwsH+uPCvBOheRl3/dARWrzN1I804di WSUDtSwL+Z0ogx3ZHz3UmhZ7vMDZzlznpE4mvZJ6Kggl69SqlMGDAN5F3plHHoupkDuA QqXrXCKYOQ8OWF9YCkeEOpjpjeoftNEy1VY6LTB9tIpKWuTc1u/pFD4UrTic7snK2GPA JIw7UetEAPUirmjq1f0UjBDkbkB/xfRm/4EXxLVMJwB2vEcPKbm0vh4HAecaQt29r5AN v7WcuCrqWNZhVwVme+DsmBnVFRIWMS3ZBZT6CvA7E2G4yEKt89FsrHTNe97UJEiSDdg0 4/SA==
X-Gm-Message-State: AGi0PubCS0pTENrNDVJn3q5d0MKSaHFgNTGtk3DwZ4ooH9WxzFmVUFoK +GYZNQjwkmraPM948QLauGNsyw==
X-Google-Smtp-Source: APiQypIcAfXCPeovUJn39T9x1phWZC0gDdKmQVMhBMt2wndRWqnYXijqNzTrbWX8kmq1WcQlrdMulA==
X-Received: by 2002:a1c:2b81:: with SMTP id r123mr29511708wmr.34.1589179262600;  Sun, 10 May 2020 23:41:02 -0700 (PDT)
Received: from p200300eb8f301f67a4ec9c1a06d87114.dip0.t-ipconnect.de (p200300EB8F301F67A4EC9C1A06D87114.dip0.t-ipconnect.de. [2003:eb:8f30:1f67:a4ec:9c1a:6d8:7114]) by smtp.gmail.com with ESMTPSA id r11sm13248067wma.35.2020.05.10.23.41.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2020 23:41:01 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <5E226F17-E2A9-4050-86F1-19483D3343E7@forgerock.com>
Date: Mon, 11 May 2020 08:41:01 +0200
Cc: Dick Hardt , Mike Jones , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5E226F17-E2A9-4050-86F1-19483D3343E7@forgerock.com>
To: Neil Madden 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 06:41:14 -0000

> On 11. May 2020, at 07:38, Neil Madden  =
wrote:
>=20
> There is no attack that this prevents so your claim of improving =
security is unsubstantiated. I can=E2=80=99t see how we can ship a =
2.1-compliant-by-default AS while this requirement remains so I don=E2=80=99=
t support it.=20

Are you saying PKCE does not prevent any attack?

>=20
> Neil
>=20
>> On 11 May 2020, at 01:35, Dick Hardt  wrote:
>>=20
>> =EF=BB=BF
>> It is a MUST to enforce consistency across all clients, and therefore =
to improve security for all clients.=20
>>=20
>> An AS can decide to be OAuth 2.1 for all new clients, and encourage =
existing clients to migrate to OAuth 2.1 (add support for PKCE).
>>=20
>> If the client wants OAuth 2.1, the AS will enforce it.
>>=20
>> I don't follow your logic below wrt. what an attacker will do.
>>=20
>>=20
>> On Sun, May 10, 2020 at 1:46 PM Neil Madden =
 wrote:
>> Let=E2=80=99s go back to basics. Why is this clause a MUST in the 2.1 =
spec? What does that accomplish?
>>=20
>> It doesn=E2=80=99t provide any security benefit - an attacker can =
just as easily send a code_challenge as a legitimate client, there=E2=80=99=
s no secret involved. So enforcing PKCE in this way doesn=E2=80=99t =
prevent any direct attacks. Presumably then making it a hard fail is =
designed to drive adoption of PKCE - turning the thumbscrews on clients =
that otherwise wouldn=E2=80=99t bother?
>>=20
>> But if we are saying that an AS can happily support legacy 2.0 =
clients without PKCE then the pressure of the MUST clause evaporates and =
they are free to ignore it again. What=E2=80=99s the incentive for an AS =
deployment to ever enforce 2.1 compliance if all it adds is a potential =
incompatibility with no security gain? (Given that servers and clients =
can already support PKCE if they wish).
>>=20
>> All I can see this doing is delaying adoption of 2.1 by ASes.
>>=20
>> =E2=80=94 Neil
>>=20
>>=20
>>> On 10 May 2020, at 21:35, Dick Hardt  wrote:
>>>=20
>>> Sounds like your clients that have set PKCE to be mandatory will =
then be OAuth 2.1 compliant with no extra work.=20
>>>=20
>>> A deployment can decide when they want to be compliant. That is not =
the specifications decision. I'm unclear on what point you are wanting =
to make below.=20
>>>=20
>>>=20
>>> On Sun, May 10, 2020 at 1:28 PM Neil Madden =
 wrote:
>>> This is the same as having 2.1 compliance turned off by default. We =
already have a per-client setting to make PKCE mandatory.
>>>=20
>>> If you can turn it off, what=E2=80=99s the point of making it a MUST =
in the spec? What does an optional MUST even mean for an AS to claim 2.1 =
compliance?
>>>=20
>>>> On 10 May 2020, at 21:19, Dick Hardt  wrote:
>>>>=20
>>>> Is there a reason why a server can not support both OAuth 2.0 and =
OAuth 2.1? The version supported could be dependent on the client id, ie =
older clients could still be OAuth 2.0, and newer clients would be OAuth =
2.1, and PKCE would be enforced.
>>>> =E1=90=A7
>>>>=20
>>>> On Sun, May 10, 2020 at 1:05 PM Neil Madden =
 wrote:
>>>> But if an AS upgrades to OAuth 2.1 then it MUST reject =
authorization requests that don=E2=80=99t include a code_challenge =
(section 4.1.2.1), so this will only be possible when all clients =
support PKCE.
>>>>=20
>>>> This makes it impossible for a 2.1-compliant AS to also support =
non-PKCE 2.0 clients (i.e., the vast majority of them).
>>>>=20
>>>> I think we can have a 2.1 spec that says clients and servers MUST =
support PKCE without this hard-fail clause.. Otherwise I can=E2=80=99t =
see how we=E2=80=99d ever ship with 2.1-compliance enabled =
out-of-the-box.
>>>>=20
>>>> =E2=80=94 Neil
>>>>=20
>>>>> On 10 May 2020, at 20:38, Dick Hardt  wrote:
>>>>>=20
>>>>> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, =
just as the other extensions. Similarly, OAuth 1.0 deployments upgrading =
to OAuth 2.0 was voluntary.=20
>>>>>=20
>>>>> Would you clarify why you think upgrading to OAuth 2.1 would be =
mandatory?
>>>>>=20
>>>>>=20
>>>>> On Sun, May 10, 2020 at 12:02 PM Mike Jones =
 wrote:
>>>>> I agree with actively maintaining and improving the OAuth 2.0 =
specs by adding enhancements that are voluntary to use.  I=E2=80=99ve =
worked on many such improvements, including Dynamic Client Registration, =
Authorization Metadata, the Device Flow, Token Exchange, DPoP, and =
support PAR and RAR, etc.  The issue that=E2=80=99s the subject is the =
current discussion is whether to make use of another enhancement, PKCE, =
mandatory in cases where it=E2=80=99s actually not needed, rather than =
making its use voluntary like the other enhancements, which I certainly =
support.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>                                                        -- Mike
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> From: Torsten Lodderstedt =
=20
>>>>> Sent: Sunday, May 10, 2020 3:15 AM
>>>>> To: Mike Jones 
>>>>> Cc: Daniel Fett ; oauth@ietf.org
>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hi Mike,
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Mike Jones  =
schrieb am Fr. 8. Mai 2020 um 18:55:
>>>>>=20
>>>>> OAuth 2.1 was supposed to not introduce breaking changes.=20
>>>>>=20
>>>>> I cannot remember the WG met that decision. Can you please refer =
to the respective thread?=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Requiring exact redirect URI matching is already a breaking =
change. Do you oppose against this as well?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> If you want to do that, please do it in TxAuth instead.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Interesting statement. Does it mean you want to conserve OAuth 2.0 =
and force any enhancements/improvements to go into TXAuth? This would =
cause huge migration efforts for existing deployments wanting to benefit =
from those enhancements.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> I think existing deployments are better served by actively =
maintaining and evolving the 2.x line. For example, PAR and RAR are =
attempts to improve OAuth 2.x and make it usable for new use cases. =
That=E2=80=99s better protection of existing investments than sending =
them of to TXAuth.
>>>>>=20
>>>>> Kind regards,
>>>>>=20
>>>>> Torsten.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>                                                        -- Mike
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> From: OAuth  On Behalf Of Daniel Fett
>>>>> Sent: Thursday, May 7, 2020 11:50 PM
>>>>> To: oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> +1 to all what Aaron said. Thanks for pointing this out!
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> We need to address this in the security BCP and this will be a =
normative change that affects OpenID Connect Core (just as our current =
recommendation on the usage of nonce).
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> We would then have:
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> - use PKCE, except if you use OIDC with a nonce, then you don't =
need PKCE, except if you are a public client, then you still need PKCE.
>>>>>=20
>>>>> - use state, except if you use PKCE, then you don't need state.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> I think there are very good reasons to simplify this down to
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> - use PKCE
>>>>>=20
>>>>> - you may or may not use state
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> First and foremost, not many people will understand why there are =
cases when the BCP/OAuth 2.1 mandate PKCE and some where they don't. =
However, understanding why you have to do something is key to =
compliance. The short version "PKCE protects the code; there is a =
specific case where it is not needed, but its better to use it all the =
time" is easy to understand. We will not see many implementations =
following the long version above correctly.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Second, we dramatically reduce technical complexity by reducing =
cases that need to be handled. We reduce correctness and compliance =
testing complexity in the same way. We reduce the cost of security =
analysis, which scales really badly to more cases.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> And finally, using nonce to protect against code injection is less =
robust than PKCE. AS have a better track record than clients when it =
comes to correctly implementing security mechanisms.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Yes, this will make a number of implementations =
non-spec-compliant, but I do not think that this is a huge problem. =
Software needs to adapt all the time and a software that has not been =
changed in a while is probably not one you would want to use anyway. We =
are setting a new goal for implementations to meet and eventually, =
maintained implementations will get there.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> -Daniel
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>>>>>=20
>>>>> Backing up a step or two, there's another point here that I think =
has been missed in these discussions.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> PKCE solves two problems: stolen authorization codes for public =
clients, and authorization code injection for all clients. We've only =
been talking about authorization code injection on the list so far. The =
quoted section of the security BCP (4.5.3) which says clients can do =
PKCE or use the nonce, is only talking about preventing authorization =
code injection.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> The nonce parameter solves authorization code injection if the =
client requests an ID token. Public clients using the nonce parameter =
are still susceptible to stolen authorization codes so they still need =
to do PKCE as well.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> The only case where OpenID Connect clients don't benefit from PKCE =
is if they are also confidential clients. Public client OIDC clients =
still need to do PKCE even if they check the nonce.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> OpenID Connect servers working with confidential clients still =
benefit from PKCE because they can then enforce the authorization code =
injection protection server-side rather than cross their fingers that =
clients implemented the nonce check properly.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> I really don't think it's worth the amount of explanation this =
will take in the future to write an exception into OAuth 2.1 or the =
Security BCP for only some types of OpenID Connect clients when all =
clients would benefit from PKCE anyway.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Aaron
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  =
wrote:
>>>>>=20
>>>>> Hello!
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This =
is best practice for OAuth 2.0. It is not common in OpenID Connect =
servers as the nonce solves some of the issues that PKCE protects =
against. We think that most OpenID Connect implementations also support =
OAuth 2.0, and hence have support for PKCE if following best practices.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> The advantages or requiring PKCE are:
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> - a simpler programming model across all OAuth applications and =
profiles as they all use PKCE
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> - reduced attack surface when using  S256 as a fingerprint of the =
verifier is sent through the browser instead of the clear text value
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> - enforcement by AS not client - makes it easier to handle for =
client developers and AS can ensure the check is conducted
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> What are disadvantages besides the potential impact to OpenID =
Connect deployments? How significant is that impact?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dick, Aaron, and Torsten
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =E1=90=A7
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> =20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> =E1=90=A7
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>> =E1=90=A7
>>=20
>> =E1=90=A7


From nobody Sun May 10 23:48:02 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35403A0857 for ; Sun, 10 May 2020 23:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0ip8cRRa1LQ for ; Sun, 10 May 2020 23:47:57 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F6A3A0853 for ; Sun, 10 May 2020 23:47:56 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id w7so9395248wre.13 for ; Sun, 10 May 2020 23:47:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=D0FK7kOSG9DQLO35lYO+Bs7dGqfT6OeS0zytzum/sMI=; b=OOXUyPurhg52JqNighFZSDPGzmOsNFTTx6yMjlByzlaQACjpU/dLP26aIBIULw0L11 4O6MrHaVOI8Z7XiB9ermtuGzrMnpKsroQTrI+cBJ8V7+MfbKbjQvbJ1Ivg5gyLOtfzW6 5SdFvMbH90DavtDW5e+nfL76nasph6lgEE/oY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=D0FK7kOSG9DQLO35lYO+Bs7dGqfT6OeS0zytzum/sMI=; b=Booy4qYWTTytb09XNqqszV9uwtDvROf7U+g+hgigHPEB5a7d2Sul+eGAdl7ai2gnoT X0XipCcCEO7pcM2vGRDneS5BpBZoik4knBt8VMIBaNcxKnEPdJpyEfitlxA3LbmbPpEd uJceqLknWEWLpUsKTuic03vvOhbfgvl0Oj3kqHv1wBg9aTHIgO7HxEzAwKwXRtHVt+0H Jk/Ti6G2YUSCvky7bkOE/zolGRqh/r+ZvpRlJWS50MawK4JbhdnVnmSKIsTfqrUVLvZh Es0M/LZZW/Ry6tmjGcwyUY/jzqOYObeGqZqLBexqHlPof2PgOG2I3f3l8Uxbg6tf0PNx sm0g==
X-Gm-Message-State: AGi0Pua87pNf62vT7hRhgxbBMhGB9RClZsnaQ3iSk0gtnWdgRx5ZD4mb wJrjtvlaTy4zdtwztDGKmgdqlsvsTWEqwtlzb+6ZG5qlcZlU5x1OAtrzS3xs3fm+PMBu5cK3Fl4 r+Lq1jJbVBtxAYBI7HQjNkM8DVb5b39TjRtVS/ndvsY8J45MPheAEPcroWhl/6yo=
X-Google-Smtp-Source: APiQypKiFZqv+wYaYxNulfuTYOLawwVFhhZZwdi54HuzMjezrPUFDzpIP9mSi456Wpfg3Hf/7NNPmA==
X-Received: by 2002:a5d:650f:: with SMTP id x15mr17058239wru.100.1589179675132;  Sun, 10 May 2020 23:47:55 -0700 (PDT)
Received: from [10.0.0.3] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id h1sm25661122wme.42.2020.05.10.23.47.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 23:47:54 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Mon, 11 May 2020 07:47:54 +0100
Message-Id: <9A3468AB-95AE-4203-BE53-89A20D048291@forgerock.com>
References: 
Cc: Dick Hardt , Mike Jones , "oauth@ietf.org" 
In-Reply-To: 
To: Torsten Lodderstedt 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 06:48:00 -0000

> On 11 May 2020, at 07:41, Torsten Lodderstedt  wr=
ote:
>=20
>> On 11. May 2020, at 07:38, Neil Madden  wrote:=

>>=20
>> There is no attack that this prevents so your claim of improving security=
 is unsubstantiated. I can=E2=80=99t see how we can ship a 2.1-compliant-by-=
default AS while this requirement remains so I don=E2=80=99t support it.=20
>=20
> Are you saying PKCE does not prevent any attack?

No, but servers and clients are already free to support PKCE. I=E2=80=99m sa=
ying that rejecting requests from non-PKCE clients doesn=E2=80=99t prevent a=
ny attack. It just denies service to legitimate clients.=20

=E2=80=94 Neil=


From nobody Mon May 11 00:05:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49783A088C for ; Mon, 11 May 2020 00:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJeRawQ9pjA1 for ; Mon, 11 May 2020 00:05:16 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72033A07DC for ; Mon, 11 May 2020 00:05:15 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id j5so9472383wrq.2 for ; Mon, 11 May 2020 00:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n+aeFESCa5MTKAncdkjEWR+m5iulNaPDddmY4tnmTAE=; b=I0YkgqkoYdFDtRcr/JjJJmifZ2qjfowtr+3USmTwLM5DARE35fi621erhCoO0DiQmj XRO1IXgcLcYcSxPO0ExlMBqJgqUxpC9LRkWp7tWI+n34jmhk255k99w6y/XD14kHEXWp jFNWpjfsT/7BMTSYgmytuaDVfUzF0UGWV60v4RVC/U5lspKyzMdI8Yb7GMtC/ZqRUU+e Lox2EtMbswK6qvMYOb5LEwOqBK/tNwCKEnGg810hM8PQ1IFmLqwgnksP/wnvEminkJnb 0tw6O0PBJ9ecJSu3zOuhFFV/VFmRljvAYlh7wvr6MwvOEhoJ3XcEiw/Xvm7MxPPGdScD Q7Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n+aeFESCa5MTKAncdkjEWR+m5iulNaPDddmY4tnmTAE=; b=oCbCxfd2FRbzEWtHCEVkWBE8TbsttdjTei/uNwIkAQWpzy1DtoDWzHxeFbsNC+7UbS OoVcvn8/44a2As/OTT9Q6WU1gyrOCFXOtNAWT5aZ+oH64V349HS3CE0HRqEBbN2H7zgS I6NbYQqIJdrvHEjOXUrL/ygksNOGT4omR8lhZXgYBVQy8QP5ccJ8W59zMeG2VRGfVWBC yLjPl/u2kauHFW0g+FGzby4nyz5gca2Dhj2UwUQJhxA15xAaR+Pwrh+ThoZhtCslaG36 RzSq6D3bARXliVxO89RbqZvq/qWUvIUIjU/+hvlrFzuraUDr1wnnQcC9VnTbZFc6iyln rQsQ==
X-Gm-Message-State: AGi0PuZDJMq3Rc4Zm/jconzbGT8/we3+TEyiNoGlmuTXr5Q17ctggtMm oZbTyaO0PzuKjAFJh3/8zFQcKg==
X-Google-Smtp-Source: APiQypIuCEK534ZV+1FGw+/HHIBz5Ziw6kaPXP0ycbO1zzk+AlGmAYBdNRZOZ2//PLDYngwVz4Kzww==
X-Received: by 2002:adf:bc41:: with SMTP id a1mr18400101wrh.302.1589180714109;  Mon, 11 May 2020 00:05:14 -0700 (PDT)
Received: from p200300eb8f301f67ddbc8b7d2a3ed8c7.dip0.t-ipconnect.de (p200300EB8F301F67DDBC8B7D2A3ED8C7.dip0.t-ipconnect.de. [2003:eb:8f30:1f67:ddbc:8b7d:2a3e:d8c7]) by smtp.gmail.com with ESMTPSA id z11sm15838055wro.48.2020.05.11.00.05.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 00:05:13 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <9A3468AB-95AE-4203-BE53-89A20D048291@forgerock.com>
Date: Mon, 11 May 2020 09:05:03 +0200
Cc: Dick Hardt , Mike Jones , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <9A3468AB-95AE-4203-BE53-89A20D048291@forgerock.com>
To: Neil Madden 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 07:05:18 -0000

> On 11. May 2020, at 08:47, Neil Madden  =
wrote:
>=20
>=20
>=20
>> On 11 May 2020, at 07:41, Torsten Lodderstedt =
 wrote:
>>=20
>>> On 11. May 2020, at 07:38, Neil Madden  =
wrote:
>>>=20
>>> There is no attack that this prevents so your claim of improving =
security is unsubstantiated. I can=E2=80=99t see how we can ship a =
2.1-compliant-by-default AS while this requirement remains so I don=E2=80=99=
t support it.=20
>>=20
>> Are you saying PKCE does not prevent any attack?
>=20
> No, but servers and clients are already free to support PKCE. I=E2=80=99=
m saying that rejecting requests from non-PKCE clients doesn=E2=80=99t =
prevent any attack. It just denies service to legitimate clients.=20

There are two aspects to this topic:

1) Do all ASs support PKCE? Requiring PKCE support fosters =
interoperability and security. Security since the client can be sure the =
AS supports PKCE. Today, if the AS does not support PKCE, the client =
will never learn since a compliant AS will just ignore additional =
request parameters.

2) Do ASs enforce PKCE? This fosters security since it forces clients to =
implement a means against code replay and CSRF.

>=20
> =E2=80=94 Neil


From nobody Mon May 11 00:20:17 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FA93A08B2 for ; Mon, 11 May 2020 00:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWK6uW6FUBYh for ; Mon, 11 May 2020 00:20:09 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868C33A0747 for ; Mon, 11 May 2020 00:20:08 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id l1so3615653qtp.6 for ; Mon, 11 May 2020 00:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ac5xlcu01hkmtkz7D672q5cbNPHEUKS1YMy5b8MU3gg=; b=2Ra++lsCEklIUKJ4zzezcKRL7Z95/NavZI50qrZSQ8gctYWxNE1qrJIOjNWETipQn1 rq4jK5aFBI6p6th/jTO17j2HjGGb8/iEGCabgenuuUxVIehewa4XxTbGuqkhaY08H9TW Yxsgf0itUd25/xjEX3SfutZUJxvneDZ2yduvHuSnuUm6QbTXgRwgmZF3HT2WILdquH2u S0fmkr/Hkb9NTq2J841aXay51UZwjKYVavpysFzHr3zWX0OdvbODLkpv1CgFiVywDSJz FzwZ6zncJWIpI/HNPTYbu0bmr2WmMp11Wf0yorP7KOr7RAOZPV8lBQ/1HVw114tY9Gxu SzFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ac5xlcu01hkmtkz7D672q5cbNPHEUKS1YMy5b8MU3gg=; b=FczaFril+TbAT+ml+4ZPWwuUHnT8hIYSbV41SpDoDbKfQkuEJgSeYpjq5ihsXq+nFN q46HFWxQZ/f/+A7XZO21K6GJvssx4yxwIIZTjPKH4wfRYlRq4/Ij3D5NZ9h1hbJF5CdQ 8cJ7p+P9STDi/PkFp7yfEjqy7TTozKlkMr0mAUpFzl7GPmsgQma/PfUrQrYSn8dUEooi 9g0G51MJvkyK5usd79vFazVn2XQsPIZiaPGYGGurR8rwFPGlnx+pb6PBvmAZ+pPMgNte aFgpenP/fsHkW3QwckrwK9B0txnuKZwSE43GRd///mxUUEQBdn7fK5/tKc4Cu93n4IIQ HMyA==
X-Gm-Message-State: AGi0PubQ/3BY/83Zx/xhWtYTdSlBfjWqBPvduVdtRN/y27DlezqadP76 JM1wV3wUC7SSWyVEnoD8andZt7HG6iZYJYnd+2Nq
X-Google-Smtp-Source: APiQypL4d3vgfXodN7iSqFWCmd2nu0hQKlPgohTxr2rOSjY3NiefUVEWMAiOAZleyrOnqVssN4dWI3MdvKLJoj19ADo=
X-Received: by 2002:ac8:6c23:: with SMTP id k3mr15055414qtu.107.1589181607163;  Mon, 11 May 2020 00:20:07 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 11 May 2020 03:20:05 -0400
From: Dominick Baier 
In-Reply-To: 
References: 
MIME-Version: 1.0
Date: Mon, 11 May 2020 03:20:05 -0400
Message-ID: 
To: Neil Madden , Dick Hardt , Mike Jones 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000002dcf7e05a55a2dbf"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 07:20:15 -0000

--0000000000002dcf7e05a55a2dbf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In IdentityServer, the PKCE requirement is per client.

We started with a default of false - and now switched to true.

FWIW
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 10. May 2020 at 22:22:35, Mike Jones (
michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote:

Exactly!



I believe that this also the same point that Brian Campbell was making
earlier about interoperability implications.



                                                       -- Mike



*From:* Neil Madden 
*Sent:* Sunday, May 10, 2020 1:06 PM
*To:* Dick Hardt 
*Cc:* Mike Jones ; oauth@ietf.org; Torsten
Lodderstedt 
*Subject:* Re: [OAUTH-WG] Re: OAuth 2.1 - require PKCE?



But if an AS upgrades to OAuth 2.1 then it MUST reject authorization
requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), so =
this
will only be possible when all clients support PKCE.



This makes it impossible for a 2.1-compliant AS to also support non-PKCE
2.0 clients (i.e., the vast majority of them).



I think we can have a 2.1 spec that says clients and servers MUST support
PKCE without this hard-fail clause. Otherwise I can=E2=80=99t see how we=E2=
=80=99d ever
ship with 2.1-compliance enabled out-of-the-box.



=E2=80=94 Neil



On 10 May 2020, at 20:38, Dick Hardt  wrote:



Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
2.0 was voluntary.



Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?





On Sun, May 10, 2020 at 12:02 PM Mike Jones  wrote:

I agree with actively maintaining and improving the OAuth 2.0 specs by
adding enhancements that are voluntary to use.  I=E2=80=99ve worked on many=
 such
improvements, including Dynamic Client Registration, Authorization
Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
etc.  The issue that=E2=80=99s the subject is the current discussion is whe=
ther to
make use of another enhancement, PKCE, mandatory in cases where it=E2=80=99=
s
actually not needed, rather than making its use voluntary like the other
enhancements, which I certainly support.



                                                       -- Mike



*From:* Torsten Lodderstedt 
*Sent:* Sunday, May 10, 2020 3:15 AM
*To:* Mike Jones 
*Cc:* Daniel Fett ; oauth@ietf.org
*Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?



Hi Mike,



Mike Jones  schrieb am Fr. =
8.
Mai 2020 um 18:55:

OAuth 2.1 was supposed to not introduce breaking changes.

I cannot remember the WG met that decision. Can you please refer to the
respective thread?



Requiring exact redirect URI matching is already a breaking change. Do you
oppose against this as well?





If you want to do that, please do it in TxAuth instead.



Interesting statement. Does it mean you want to conserve OAuth 2.0 and
force any enhancements/improvements to go into TXAuth? This would cause
huge migration efforts for existing deployments wanting to benefit from
those enhancements.



I think existing deployments are better served by actively maintaining and
evolving the 2.x line. For example, PAR and RAR are attempts to improve
OAuth 2.x and make it usable for new use cases. That=E2=80=99s better prote=
ction of
existing investments than sending them of to TXAuth.

Kind regards,

Torsten.





                                                       -- Mike



*From:* OAuth  *On Behalf Of *Daniel Fett
*Sent:* Thursday, May 7, 2020 11:50 PM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?



+1 to all what Aaron said. Thanks for pointing this out!



We need to address this in the security BCP and this will be a normative
change that affects OpenID Connect Core (just as our current recommendation
on the usage of nonce).



We would then have:



- use PKCE, except if you use OIDC with a nonce, then you don't need PKCE,
except if you are a public client, then you still need PKCE.

- use state, except if you use PKCE, then you don't need state.



I think there are very good reasons to simplify this down to



- use PKCE

- you may or may not use state



First and foremost, not many people will understand why there are cases
when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
understanding *why* you have to do something is key to compliance. The
short version "PKCE protects the code; there is a specific case where it is
not needed, but its better to use it all the time" is easy to understand.
We will not see many implementations following the long version above
correctly.



Second, we dramatically reduce technical complexity by reducing cases that
need to be handled. We reduce correctness and compliance testing complexity
in the same way. We reduce the cost of security analysis, which scales
really badly to more cases.



And finally, using nonce to protect against code injection is less robust
than PKCE. AS have a better track record than clients when it comes to
correctly implementing security mechanisms.



Yes, this will make a number of implementations non-spec-compliant, but I
do not think that this is a huge problem. Software needs to adapt all the
time and a software that has not been changed in a while is probably not
one you would want to use anyway. We are setting a new goal for
implementations to meet and eventually, maintained implementations will get
there.



-Daniel





Am 08.05.20 um 01:38 schrieb Aaron Parecki:

Backing up a step or two, there's another point here that I think has been
missed in these discussions.



PKCE solves two problems: stolen authorization codes for public clients,
and authorization code injection for all clients. We've only been talking
about authorization code injection on the list so far. The quoted section
of the security BCP (4.5.3) which says clients can do PKCE or use the
nonce, is only talking about preventing authorization code injection.



The nonce parameter solves authorization code injection if the client
requests an ID token. Public clients using the nonce parameter are still
susceptible to stolen authorization codes so they still need to do PKCE as
well.



The only case where OpenID Connect clients don't benefit from PKCE is if
they are also confidential clients. Public client OIDC clients still need
to do PKCE even if they check the nonce.



OpenID Connect servers working with confidential clients still benefit from
PKCE because they can then enforce the authorization code injection
protection server-side rather than cross their fingers that clients
implemented the nonce check properly.



I really don't think it's worth the amount of explanation this will take in
the future to write an exception into OAuth 2.1 or the Security BCP for
only some types of OpenID Connect clients when all clients would benefit
from PKCE anyway.



Aaron







On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:

Hello!



We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best
practice for OAuth 2.0. It is not common in OpenID Connect servers as the
nonce solves some of the issues that PKCE protects against. We think that
most OpenID Connect implementations also support OAuth 2.0, and hence have
support for PKCE if following best practices.



The advantages or requiring PKCE are:



- a simpler programming model across all OAuth applications and profiles as
they all use PKCE



- reduced attack surface when using  S256 as a fingerprint of the verifier
is sent through the browser instead of the clear text value



- enforcement by AS not client - makes it easier to handle for client
developers and AS can ensure the check is conducted



What are disadvantages besides the potential impact to OpenID Connect
deployments? How significant is that impact?



Dick, Aaron, and Torsten



=E1=90=A7



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



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

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

=E1=90=A7

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


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

--0000000000002dcf7e05a55a2dbf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

In I=
dentityServer, the PKCE requirement is per client.

We started with a default of false - and no=
w switched to true.

FWIW
 
=E2=80=94=E2=80=94=E2=80=94
=
Dominick Baier
 
On 10. May 2020 at 2=
2:22:35, Mike Jones (michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote:
 =











Exactly!


=C2=A0


I believe that this al=
so the same point that Brian Campbell was making earlier about interoperabi=
lity implications.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=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: Neil Madden <neil.madden@forgerock.com> 

Sent: Sunday, May 10, 2020 1:06 PM

To: Dick Hardt <dick.hard=
t@gmail.com>

Cc: Mike Jones <Mi=
chael.Jones@microsoft.com>; oauth@=
ietf.org; Torsten Lodderstedt <torsten@lodderstedt.net>

Subject: Re: [OAUTH-WG] Re: OAuth 2.1 - require PKCE?






=C2=A0


But if an AS upgrades to OAuth 2.1 then it MUST reje=
ct authorization requests that don=E2=80=99t include a code_challenge (sect=
ion 4.1.2.1), so this will only be possible when all clients support PKCE.<=
/p>



=C2=A0






This makes it impossible for a 2.1-compliant AS to a=
lso support non-PKCE 2.0 clients (i.e., the vast majority of them).




=C2=A0








I think we can have a 2.1 spec that says clients and=
 servers MUST support PKCE without this hard-fail clause. Otherwise I can=
=E2=80=99t see how we=E2=80=99d ever ship with 2.1-compliance enabled out-o=
f-the-box.






=C2=A0






=E2=80=94 Neil






=C2=A0










On 10 May 2020, at 20:38, Dick Hardt <dick.hardt@gmail.com> wrote:




=C2=A0








Hi Mike, I would consider upgrading to OAuth 2.1 to =
be voluntary, just as the other extensions. Similarly, OAuth 1.0 deployment=
s upgrading to OAuth 2.0 was voluntary.=C2=A0




=C2=A0






Would you clarify why you think upgrading=C2=A0to OA=
uth 2.1 would be mandatory?






=C2=A0






=C2=A0






On Sun, May 10, 2020 at 12:02 PM Mike Jones <Mich=
ael.Jones=3D40microsoft.c=
om@dmarc.ietf.org> wrote:










I agree with actively maintaining an=
d improving the OAuth 2.0 specs by adding enhancements that are voluntary t=
o use.=C2=A0 I=E2=80=99ve worked on many such improvements,
 including Dynamic Client Registration, Authorization Metadata, the Device =
Flow, Token Exchange, DPoP, and support PAR and RAR, etc.=C2=A0 The issue t=
hat=E2=80=99s the subject is the current discussion is whether to make use =
of another enhancement, PKCE, mandatory in cases
 where it=E2=80=99s actually not needed, rather than making its use volunta=
ry like the other enhancements, which I certainly support.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.=
ietf.org>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>;
oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hi Mike,








=C2=A0






Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> sch=
rieb am Fr. 8. Mai 2020 um 18:55:










OAuth 2.1 was supposed to not introd=
uce breaking changes.=C2=A0










I cannot remember the WG met that decision. Can you please refer t=
o the respective thread?=C2=A0






=C2=A0






Requiring exact redirect URI matching is already a breaking change=
. Do you oppose against this as well?






=C2=A0






=C2=A0










If you want to do that, please do it=
 in TxAuth instead.










=C2=A0






Interesting statement. Does it mean you want to conserve OAuth 2.0=
 and force any enhancements/improvements to go into TXAuth? This would caus=
e huge migration efforts for existing
 deployments wanting to benefit from those enhancements.






=C2=A0






I think existing deployments are better served by actively maintai=
ning and evolving the 2.x line. For example, PAR and RAR are attempts to im=
prove OAuth 2.x and make it usable for
 new use cases. That=E2=80=99s better protection of existing investments th=
an sending them of to TXAuth.






Kind regards,






Torsten.






=C2=A0










=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?






=C2=A0




+1 to all what Aaron said. Thanks for pointing this out!






=C2=A0






We need to address this in the security BCP and this will be a nor=
mative change that affects OpenID Connect Core (just as our current recomme=
ndation on the usage of nonce).






=C2=A0






We would then have:






=C2=A0






- use PKCE, except if you use OIDC with a nonce, then you don'=
t need PKCE, except if you are a public client, then you still need PKCE.





- use state, except if you use PKCE, then you don't need state=
.






=C2=A0






I think there are very good reasons to simplify this down to







=C2=A0






- use PKCE






- you may or may not use state






=C2=A0






First and foremost, not many people will understand why there are =
cases when the BCP/OAuth 2.1 mandate PKCE and some where they don't. Ho=
wever, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.






=C2=A0






Second, we dramatically reduce technical complexity by reducing ca=
ses that need to be handled. We reduce correctness and compliance testing c=
omplexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.





=C2=A0






And finally, using nonce to protect against code injection is less=
 robust than PKCE. AS have a better track record than clients when it comes=
 to correctly implementing security
 mechanisms. 






=C2=A0






Yes, this will make a number of implementations non-spec-compliant=
, but I do not think that this is a huge problem. Software needs to adapt a=
ll the time and a software that has
 not been changed in a while is probably not one you would want to use anyw=
ay. We are setting a new goal for implementations to meet and eventually, m=
aintained implementations will get there.






=C2=A0






-Daniel






=C2=A0






=C2=A0






Am 08.05.20 um 01:38 schrieb Aaron Parecki:










Backing up a step or two, there's another point here that I th=
ink has been missed in these discussions.





=C2=A0






PKCE solves two problems: stolen authorization codes for public cl=
ients, and authorization code injection for all clients. We've only bee=
n talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.






=C2=A0






The nonce parameter solves authorization code injection if the cli=
ent requests an ID token. Public clients using the nonce parameter are stil=
l susceptible to stolen authorization
 codes so they still need to do PKCE as well.






=C2=A0






The only case where OpenID Connect clients don't benefit from =
PKCE is if they are also confidential clients. Public client OIDC clients s=
till need to do PKCE even if they check
 the nonce.






=C2=A0






OpenID Connect servers working with confidential clients still ben=
efit from PKCE because they can then enforce the authorization code injecti=
on protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.






=C2=A0






I really don't think it's worth the amount of explanation =
this will take in the future to write an exception into OAuth 2.1 or the Se=
curity BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.






=C2=A0






Aaron






=C2=A0








=C2=A0




=C2=A0






On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:<=
/p>









Hello!





=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 code flows. This=
 is best practice for OAuth 2.0. It is not common in OpenID Connect servers=
 as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:






=C2=A0






- a simpler programming model across all OAuth applications and pr=
ofiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a fingerprint of=
 the verifier is sent through the browser instead of the clear text value





=C2=A0






- enforcement by AS not client - makes it easier to handle for cli=
ent developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact to OpenID Conn=
ect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7










=C2=A0


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0






_______________________________________________

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










=
=E1=90=A7




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth








=C2=A0









_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.iet=
f.org/mailman/listinfo/oauth



--0000000000002dcf7e05a55a2dbf--


From nobody Mon May 11 00:34:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF513A08B7 for ; Mon, 11 May 2020 00:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wds1qEiPQEJ for ; Mon, 11 May 2020 00:34:08 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6414D3A08BE for ; Mon, 11 May 2020 00:34:08 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id k12so16852220wmj.3 for ; Mon, 11 May 2020 00:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=8ny3cbRld1CNIj9MXG2R6eKEF42+1B5PUlFKRbZ6c28=; b=dcppsa0YwuE8LldoEYl1P1adVu4UnDkoqvPJybLloiFJj3tXpz/fgagPB20m0m6zzn 4XZF1PW7Pua89kjfc9q/MJ8vpeAwAOkoCPK76biRzt3Si0XwOL9ouThgKV6/qlBsNROq jFVmFKI9CyUaGC8u9INFlwkv3V3hBxXjQ0sHs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=8ny3cbRld1CNIj9MXG2R6eKEF42+1B5PUlFKRbZ6c28=; b=UQyVmwqKdXJxNcMJ+WkHEHU1jYN7jWfB0XeRbP6kJzEOA4hOyNvXDIHx6L6isSPcIX frZ+AJj16GqSkHwyYxZxEoDpTL+ypC2D2tUOANPK6WRl+gTNDOm87rKM5nV3NE76fYy/ 7Aka2jdTaDSxImv+o0ZO0Mp/KC6LPaCzWbzHKurS4ofTo69QlW+USa8ui+kuLTNgkVSo F73GMKys8OMAvtJfq53nqq4u8Ij+wOsWsn5tio2N3G8Im7NvJeuj/BghkLuJ7N7bae/m LL7G/mx9XVuShRm1qCiAYXwbSfla2Qz9GmNiwcVOv1pcU5Jo5Fx6Qnoj7LbcSkVteGja Sb3Q==
X-Gm-Message-State: AGi0PuboQgDntfo4KYy4/49Cxubu9fUYJhvR1I7hxkeFq2mT9nVxK/88 OjEwcZG2WtylwO4fQzeAMcGimsm6nZ/37kHDo8v9R2/yufUK9SD0duaoMNeLswExHqwHKWD649d TBoWKR4DEb2m8unSnTDcRyEUTjkeP0k0PTEMtYfV2Bzyq365GE4ZcicIbdKMZFoA=
X-Google-Smtp-Source: APiQypJzZn+svWh7Xa+8NyVWjz7FACmhYfynkSNOIQtCIaWKfN/gweFg5hFopcgv8msIkSehNgwdkQ==
X-Received: by 2002:a1c:b60b:: with SMTP id g11mr1939389wmf.49.1589182446014;  Mon, 11 May 2020 00:34:06 -0700 (PDT)
Received: from [10.0.0.3] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id f5sm16132614wrp.70.2020.05.11.00.34.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 00:34:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Mon, 11 May 2020 08:34:04 +0100
Message-Id: 
References: 
Cc: Dick Hardt , Mike Jones , "oauth@ietf.org" 
In-Reply-To: 
To: Torsten Lodderstedt 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 07:34:13 -0000

> On 11 May 2020, at 08:05, Torsten Lodderstedt  wr=
ote:
>=20
> =EF=BB=BF
>=20
>>> On 11. May 2020, at 08:47, Neil Madden  wrote=
:
>>>=20
>>>=20
>>>=20
>>>> On 11 May 2020, at 07:41, Torsten Lodderstedt =
 wrote:
>>>=20
>>>> On 11. May 2020, at 07:38, Neil Madden  wrot=
e:
>>>>=20
>>>> There is no attack that this prevents so your claim of improving securi=
ty is unsubstantiated. I can=E2=80=99t see how we can ship a 2.1-compliant-b=
y-default AS while this requirement remains so I don=E2=80=99t support it.=20=

>>>=20
>>> Are you saying PKCE does not prevent any attack?
>>=20
>> No, but servers and clients are already free to support PKCE. I=E2=80=99m=
 saying that rejecting requests from non-PKCE clients doesn=E2=80=99t preven=
t any attack. It just denies service to legitimate clients.=20
>=20
> There are two aspects to this topic:
>=20
> 1) Do all ASs support PKCE? Requiring PKCE support fosters interoperabilit=
y and security. Security since the client can be sure the AS supports PKCE. T=
oday, if the AS does not support PKCE, the client will never learn since a c=
ompliant AS will just ignore additional request parameters.

But just saying that a 2.1 AS MUST support PKCE is enough for this. Rejectin=
g requests just to support feature discovery is a sledgehammer to crack a nu=
t.=20

>=20
> 2) Do ASs enforce PKCE? This fosters security since it forces clients to i=
mplement a means against code replay and CSRF.
>=20

Again, just saying that 2.1 clients MUST support PKCE achieves this aim. Rej=
ecting non-PKCE requests doesn=E2=80=99t add anything to security.=20

And as has been pointed out elsewhere in this thread there are clients that d=
on=E2=80=99t benefit from PKCE such as confidential OIDC clients. Indeed for=
 most confidential clients the gains of PKCE are relatively minor - code inj=
ection attacks are already pretty hard to pull off in practice against such c=
lients.=20

Neil=


From nobody Mon May 11 00:54:01 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34663A08DA for ; Mon, 11 May 2020 00:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZCtrlmp8sJD for ; Mon, 11 May 2020 00:53:57 -0700 (PDT)
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A053A08D7 for ; Mon, 11 May 2020 00:53:56 -0700 (PDT)
Received: by mail-wr1-x442.google.com with SMTP id x17so9641396wrt.5 for ; Mon, 11 May 2020 00:53:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JDGPMgk7vqZbTh+wc4dueEL8iKlktGFAomDjkiaRjTM=; b=S1c1DA1S8OtTTqOMeVKsL8NZw9mA6chwmCmwX55oDkjyyQhMGy56pd9Fczh4pyCdWy Zx9lEbrjzZqchZKVjGq7EoxByvB+qTHn1nEFJn1fEdeTmeaLTHka16u2fgIq47jtwrAm +2L31JfOQ4uO2brIvRuAdoYeQ/QOnPx1V+WVx1BDYLHobLnGrwsrj9izhwWtc9ohN/CU Fmswcuw1Dp8MX6OPk7/rM8Eo7mBGCpOnepqVb4kPr/VGT4sPCFNuZbjDlzYEhxd++hhG ANJz1gm2NB7Wm3fE16eijFH6PSz8ZQYleAS6vGXRyCppQPwLnrtOLiIPSschAsk7TT2M ZWfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JDGPMgk7vqZbTh+wc4dueEL8iKlktGFAomDjkiaRjTM=; b=ItKOf35A05IpSlAuUbrwu/Xv8X+Oe50+NKE6tBtnUnOIivxB1UBC4xnMl3P1c9cGUB EPuViFSQQejJve0RRKUsxrprWon0qKdWrBAkbz90Ncsano2lChzRA5Cd3kcFdpDcMfp5 Pt+yACesKOl4JTitweGVX2ONGFgOTSjIzUHJERKcYJUNS8xPHaUKQv8pG/H0Pr1c6yBM 0w1dazX+O7LhWK4IFYPfLq1HSrIPNM8Y4GXcslkZP+LA6760HkDnlhknyVf6IVcQh6oq rkNJNXhbWou+Xe4HKWrt9lCbIGkaFrZdxHe5gNVUSvvOYoXrAqzeDfJgEyGBa1m0EUv4 UDDg==
X-Gm-Message-State: AGi0PuaiXYTVBmaEa6upuX4RGAgBHK8yNhXKNThNYSCQOD2ZcY76FAd9 MPsmh5RZZ5kOWkQ0Mpx1gM1NKA==
X-Google-Smtp-Source: APiQypLX8LSkx0OkmG+3cLXOg+FO6qsQjJ21Txlv+kCI7RG/8TM+d3bY064xEqFLOLrXrNTlh23B3Q==
X-Received: by 2002:a5d:49ca:: with SMTP id t10mr9850168wrs.285.1589183635423;  Mon, 11 May 2020 00:53:55 -0700 (PDT)
Received: from p200300eb8f301f67ddbc8b7d2a3ed8c7.dip0.t-ipconnect.de (p200300EB8F301F67DDBC8B7D2A3ED8C7.dip0.t-ipconnect.de. [2003:eb:8f30:1f67:ddbc:8b7d:2a3e:d8c7]) by smtp.gmail.com with ESMTPSA id w9sm17391178wrc.27.2020.05.11.00.53.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 00:53:54 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Mon, 11 May 2020 09:53:53 +0200
Cc: Dick Hardt , Mike Jones , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EAF68CC-0094-4BAA-BA47-2A69CD2D3D8A@lodderstedt.net>
References:  
To: Neil Madden 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 07:53:59 -0000

> On 11. May 2020, at 09:34, Neil Madden  =
wrote:
>=20
>=20
>=20
>> On 11 May 2020, at 08:05, Torsten Lodderstedt =
 wrote:
>>=20
>> =EF=BB=BF
>>=20
>>>> On 11. May 2020, at 08:47, Neil Madden  =
wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> On 11 May 2020, at 07:41, Torsten Lodderstedt =
 wrote:
>>>>=20
>>>>> On 11. May 2020, at 07:38, Neil Madden  =
wrote:
>>>>>=20
>>>>> There is no attack that this prevents so your claim of improving =
security is unsubstantiated. I can=E2=80=99t see how we can ship a =
2.1-compliant-by-default AS while this requirement remains so I don=E2=80=99=
t support it.=20
>>>>=20
>>>> Are you saying PKCE does not prevent any attack?
>>>=20
>>> No, but servers and clients are already free to support PKCE. I=E2=80=99=
m saying that rejecting requests from non-PKCE clients doesn=E2=80=99t =
prevent any attack. It just denies service to legitimate clients.=20
>>=20
>> There are two aspects to this topic:
>>=20
>> 1) Do all ASs support PKCE? Requiring PKCE support fosters =
interoperability and security. Security since the client can be sure the =
AS supports PKCE. Today, if the AS does not support PKCE, the client =
will never learn since a compliant AS will just ignore additional =
request parameters.
>=20
> But just saying that a 2.1 AS MUST support PKCE is enough for this. =
Rejecting requests just to support feature discovery is a sledgehammer =
to crack a nut.=20
>=20
>>=20
>> 2) Do ASs enforce PKCE? This fosters security since it forces clients =
to implement a means against code replay and CSRF.
>>=20
>=20
> Again, just saying that 2.1 clients MUST support PKCE achieves this =
aim. Rejecting non-PKCE requests doesn=E2=80=99t add anything to =
security.=20
>=20
> And as has been pointed out elsewhere in this thread there are clients =
that don=E2=80=99t benefit from PKCE such as confidential OIDC clients. =
Indeed for most confidential clients the gains of PKCE are relatively =
minor - code injection attacks are already pretty hard to pull off in =
practice against such clients.=20

I agree, but I wouldn=E2=80=99t say they don=E2=80=99t benefit at all.=20=


1) The nonce check happens after the OP had issued the ID Token. This =
means even if the transaction is being evaluated to be fraudulent =
afterwards, the OP releases PII to the RP. Depending on the way the OP =
obtained this data, this might have already caused unneglectable cost =
(e.g. for an external commercial claims provider).

That=E2=80=99s not the case with PKCE.

2) The whole check relies on the client. I would rather rely on the =
OP/AS to enforce this security check since clients have a less promising =
track record of implementing security checks.=20

3) In mixed OAuth/OIDC scenarios, switching back and force between nonce =
and PKCE does not make developers live simpler.=20

>=20
> Neil


From nobody Mon May 11 01:15:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6C3A08B8 for ; Mon, 11 May 2020 01:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pwg0Q918XUad for ; Mon, 11 May 2020 01:15:12 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38533A08DC for ; Mon, 11 May 2020 01:15:11 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id s186so7044180qkd.4 for ; Mon, 11 May 2020 01:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=t/CYaxUohdGLdKhXG2sQ3GSPmaChyVrt6t7a5HVKsRc=; b=PgGiLqvXKKKB+IH+a6k0v41CiT0ao7aX2ecFO4s7gKdcBgxUeDorOboP+QkBl+Q1rm WiwHc8Oz7STi/s8bUsCU2nzSzELNTjg76OYXl7NdVFF7MuUKGpuiNpYYaErPj7mc+gm3 ysBg3en1njGz4AUuoyV1CWYGC8xEGo3KLYQmbqM4f39gRV6pqwvakdfwO6Cwz+KiO4oA OUxa82bAB7PjBKK17OVV9AXafgXQSeXOA/QpW1FgkSTxtjwneSRSaBjtt8zTdK6SQtlT eeXOGywWjAjUHVWdV2TXtkmM9ZqaStUIsCiOLNxfhkvK8P3+0N1fGNLTaOk+P82ljmTY wCog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=t/CYaxUohdGLdKhXG2sQ3GSPmaChyVrt6t7a5HVKsRc=; b=FH+JCLU94vRcUAvklFEpKf2/HBludDm6wQWaZPoZlMQXSCJtQD8UtH76A9HNJ50s0s +q4z3HBMDjE97RFm6K24w8fgSfcKcLCsBStHkjkTje/GRQEoDmePFpQltLLqoJA1glJE QOf3aqFj/xz6nUwwkQhGTeeJiHxDyBPt5RGmGnuDyuJGQmfMct5rFkQ4IAKneLDg+gxO LKtDmvs7s917vWlvAhlpEa8HiWLi4sjz8brdNIycTniuFZsjkeLftVhpgmIi3jg+ffEu q9HV9f1RtfEN4ARoWoAbs2oNYl3YD6V4YAzfWY7B+tNns34kCna700v3W7D7ZJze7nGC uoJg==
X-Gm-Message-State: AGi0PubbVIdCM/8LdDOqajH3YcgKQ9wkJpI+vzpxCPINQjiPYslzJWyi zzuqybPlE8Bs0I0k3r9mzp8/zrc7Gf5+c2N8PDbc
X-Google-Smtp-Source: APiQypJ+IGt5Itpnfmiid8hwt+tpACU/CXZ8dr8moTJoa/EwLwQS/7hCfkXCRKQuwIxXXSvpYdN1+eUUu4LODwuk1a0=
X-Received: by 2002:a37:688c:: with SMTP id d134mr14354501qkc.450.1589184910677;  Mon, 11 May 2020 01:15:10 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 11 May 2020 04:15:10 -0400
From: Dominick Baier 
In-Reply-To: 
References: 
MIME-Version: 1.0
Date: Mon, 11 May 2020 04:15:10 -0400
Message-ID: 
To: Brock Allen , oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000156bec05a55af2bc"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwsreq-21
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 08:15:15 -0000

--000000000000156bec05a55af2bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Would be also interested in the official language here.

Would an implementation need to introduce an optional  =E2=80=9Cstrict JAR
validation mode=E2=80=9D  - which complies with JAR, but breaks OIDC compat=
ibility?

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 7. May 2020 at 15:32:33, Brock Allen (brockallen@gmail.com) wrote:

Perhaps quite late, but a few comments/questions related to this:

1) When decoded, all the JWT samples are missing the "typ" claim from the
header, which I think should be "oauth.authz.req+jwt".

2) When validating the JAR if we are to validate the "typ" then this would
be incompatible with OIDC's request object, I think?

3) When the JAR is passed by reference, then the HTTP response Content-Type
of "application/oauth.authz.req+jwt" would also seem to break or be
incompatible with OIDC's request object passed by reference?

There might need to be clarification when mixing this w/ an OIDC OP
implementation.

TIA

-Brock

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

--000000000000156bec05a55af2bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Woul=
d be also interested in the official language here.

Would an implementation need to introduce =
an optional =C2=A0=E2=80=9Cstrict JAR validation mode=E2=80=9D =C2=A0- whic=
h complies with JAR, but breaks OIDC compatibility?
 
 
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier
 
On 7. May 2020 at 15:32:33, Brock Allen (<=
a href=3D"mailto:brockallen@gmail.com">brockallen@gmail.com) wrote:
=
 
Perhaps quite late, but a few comments/questions re=
lated to this:

1) When decoded, all the JWT samples are =
missing the "typ" claim from the header, which I think should be =
"oauth.authz.req+jwt".

2) When validatin=
g the JAR if we are to validate the "typ" then this would be inco=
mpatible with OIDC's request object, I think?

=
3) When the JAR is passed by reference, then the HTTP response Content-Type=
 of=C2=A0"application/oauth.authz.req+jwt" would also seem to bre=
ak or be incompatible with OIDC's request object passed by reference?

There might need to be clarification when mixing th=
is w/ an OIDC OP implementation.=C2=A0

TIA
<=
div>

-Brock

<=
/div>_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.iet=
f.org/mailman/listinfo/oauth



--000000000000156bec05a55af2bc--


From nobody Mon May 11 01:59:56 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20D3A09F0 for ; Mon, 11 May 2020 01:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVm2z0dxUOvv for ; Mon, 11 May 2020 01:59:49 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B813A09BC for ; Mon, 11 May 2020 01:59:43 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id w7so9876929wre.13 for ; Mon, 11 May 2020 01:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lcbHpT6uQQhfYlIkzQ04panXYyynu/hsQWoD/ihWMtM=; b=hmXoTI7g94JYoyniP48dyViJUHoaw1E2PPUsCWRJtSH/xV4qIhiuefUazo0WmIKSpq KLQyOIf3X7ZxCg209x9cJpGodYDue4rAChI+yFssXaJwzxkwTGLrkwS9y8d1qqp0kW2V 8A4DjOGEenDC4z0vCsE8JczQOoiU2XQq6lz6U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lcbHpT6uQQhfYlIkzQ04panXYyynu/hsQWoD/ihWMtM=; b=lBxVnnmAYrJS8ufz8TKjmrrtAPa1Cs9Br8c6/xN41vVfF8YftPucgzL8Hdz1qbL+61 2z/4TnMLlrj1o2QVVDWKo2Ey/DylZPiz4MEkNxvSltfK2JHkaN+yfqimy6cPHGSUtIlS cUYqPfZ3eHDFuWmvpG0MJDzY2099pfTknnlHRmJxBaY5qCZRNCUNgNr3Mb7VMx/ThV3I /cQRMI3unPidcUgo4f+OVTAtDVwVkr6JgqntnM3u/489Hy3f0xfKtLkbiB/cjVE+7xIH OJ9HDXvsfVMLLFVHN9BRoVybOYGr3sOhcae3jW4PC3AseTrRZyZnCyvApM0iXz+N/5oV 3Udw==
X-Gm-Message-State: AGi0PubklRc2GjeQ6Tbg+n2FpeXCFDWZ9hrHymfemhocgSNd/iv4u4W9 mwmzdsmiXLhyjJ3QThsyrOba8w==
X-Google-Smtp-Source: APiQypIjVk8R62MeeLK/x9dJOF6Sqm+2ZTTu99NrEe//YJ1ZfCO7tqDdGtuot6WwUIoEKySDYz9r7Q==
X-Received: by 2002:adf:fa44:: with SMTP id y4mr4923331wrr.135.1589187582147;  Mon, 11 May 2020 01:59:42 -0700 (PDT)
Received: from [10.0.0.2] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id 128sm19381045wme.39.2020.05.11.01.59.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 01:59:41 -0700 (PDT)
From: Neil Madden 
Message-Id: <02581F0B-F4BC-4EBD-860C-3DAFA631BA40@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C63A8535-4D6E-4D21-8F83-0001088A9B6B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 11 May 2020 09:59:40 +0100
In-Reply-To: <8EAF68CC-0094-4BAA-BA47-2A69CD2D3D8A@lodderstedt.net>
Cc: Dick Hardt , Mike Jones , "oauth@ietf.org" 
To: Torsten Lodderstedt 
References:   <8EAF68CC-0094-4BAA-BA47-2A69CD2D3D8A@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 08:59:56 -0000

--Apple-Mail=_C63A8535-4D6E-4D21-8F83-0001088A9B6B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 11 May 2020, at 08:53, Torsten Lodderstedt =
 wrote:
>=20
>=20
>=20
>> On 11. May 2020, at 09:34, Neil Madden  =
wrote:
>>=20
>>=20
>>=20
>>> On 11 May 2020, at 08:05, Torsten Lodderstedt =
 wrote:
>>>=20
>>> =EF=BB=BF
>>>=20
>>>>> On 11. May 2020, at 08:47, Neil Madden  =
wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On 11 May 2020, at 07:41, Torsten Lodderstedt =
 wrote:
>>>>>=20
>>>>>> On 11. May 2020, at 07:38, Neil Madden =
 wrote:
>>>>>>=20
>>>>>> There is no attack that this prevents so your claim of improving =
security is unsubstantiated. I can=E2=80=99t see how we can ship a =
2.1-compliant-by-default AS while this requirement remains so I don=E2=80=99=
t support it.=20
>>>>>=20
>>>>> Are you saying PKCE does not prevent any attack?
>>>>=20
>>>> No, but servers and clients are already free to support PKCE. I=E2=80=
=99m saying that rejecting requests from non-PKCE clients doesn=E2=80=99t =
prevent any attack. It just denies service to legitimate clients.=20
>>>=20
>>> There are two aspects to this topic:
>>>=20
>>> 1) Do all ASs support PKCE? Requiring PKCE support fosters =
interoperability and security. Security since the client can be sure the =
AS supports PKCE. Today, if the AS does not support PKCE, the client =
will never learn since a compliant AS will just ignore additional =
request parameters.
>>=20
>> But just saying that a 2.1 AS MUST support PKCE is enough for this. =
Rejecting requests just to support feature discovery is a sledgehammer =
to crack a nut.=20
>>=20
>>>=20
>>> 2) Do ASs enforce PKCE? This fosters security since it forces =
clients to implement a means against code replay and CSRF.
>>>=20
>>=20
>> Again, just saying that 2.1 clients MUST support PKCE achieves this =
aim. Rejecting non-PKCE requests doesn=E2=80=99t add anything to =
security.=20
>>=20
>> And as has been pointed out elsewhere in this thread there are =
clients that don=E2=80=99t benefit from PKCE such as confidential OIDC =
clients. Indeed for most confidential clients the gains of PKCE are =
relatively minor - code injection attacks are already pretty hard to =
pull off in practice against such clients.=20
>=20
> I agree, but I wouldn=E2=80=99t say they don=E2=80=99t benefit at all.=20=

>=20
> 1) The nonce check happens after the OP had issued the ID Token. This =
means even if the transaction is being evaluated to be fraudulent =
afterwards, the OP releases PII to the RP. Depending on the way the OP =
obtained this data, this might have already caused unneglectable cost =
(e.g. for an external commercial claims provider).
>=20
> That=E2=80=99s not the case with PKCE.

We=E2=80=99re talking about confidential clients. If the ID Token is not =
meant for this client then client authentication will fail, or else the =
auth code was meant for this client (but not this session) in which case =
the user already consented to release of PII to that RP.

If you are talking about a hybrid flow then PKCE doesn=E2=80=99t protect =
that either. I=E2=80=99d like to see encrypted ID tokens become =
mandatory in hybrid flows, but that=E2=80=99s not for this WG.

>=20
> 2) The whole check relies on the client. I would rather rely on the =
OP/AS to enforce this security check since clients have a less promising =
track record of implementing security checks.=20
>=20
> 3) In mixed OAuth/OIDC scenarios, switching back and force between =
nonce and PKCE does not make developers live simpler.=20

Maybe, but I don=E2=80=99t think either of these rise to the level of =
mandating that ASes reject non-PKCE requests.

In the interests of building consensus, maybe something along the lines =
of: =E2=80=9CAn AS MUST reject requests without a code_challenge from =
public clients, and SHOULD reject such requests from other clients =
unless there is reasonable assurance that the client mitigates these =
threats in other ways=E2=80=9D?

=E2=80=94 Neil


--Apple-Mail=_C63A8535-4D6E-4D21-8F83-0001088A9B6B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8





On 11 May 2020, at 08:53, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



On 11. May 2020, at 09:34, Neil =
Madden <neil.madden@forgerock.com> wrote:



On 11 May 2020, at 08:05, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=EF=BB=BF

On 11. May =
2020, at 08:47, Neil Madden <neil.madden@forgerock.com> wrote:



On 11 May 2020, at 07:41, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

On 11. May 2020, at 07:38, Neil Madden <neil.madden@forgerock.com> wrote:

There is no attack that this prevents so your claim of =
improving security is unsubstantiated. I can=E2=80=99t see how we can =
ship a 2.1-compliant-by-default AS while this requirement remains so I =
don=E2=80=99t support it. 

Are you saying PKCE does not =
prevent any attack?

No, but =
servers and clients are already free to support PKCE. I=E2=80=99m saying =
that rejecting requests from non-PKCE clients doesn=E2=80=99t prevent =
any attack. It just denies service to legitimate clients. 

There are two aspects to this =
topic:

1) Do all ASs support PKCE? =
Requiring PKCE support fosters interoperability and security. Security =
since the client can be sure the AS supports PKCE. Today, if the AS does =
not support PKCE, the client will never learn since a compliant AS will =
just ignore additional request parameters.

But just saying that a 2.1 AS MUST support PKCE is enough for =
this. Rejecting requests just to support feature discovery is a =
sledgehammer to crack a nut. 


2) Do ASs =
enforce PKCE? This fosters security since it forces clients to implement =
a means against code replay and CSRF.


Again, just saying that 2.1 =
clients MUST support PKCE achieves this aim. Rejecting non-PKCE requests =
doesn=E2=80=99t add anything to security. 

And as has been pointed out elsewhere in this thread there =
are clients that don=E2=80=99t benefit from PKCE such as confidential =
OIDC clients. Indeed for most confidential clients the gains of PKCE are =
relatively minor - code injection attacks are already pretty hard to =
pull off in practice against such clients. 

I agree, but I wouldn=E2=80=99t say they don=E2=80=99t =
benefit at all. 

1) The nonce check happens after the OP had issued the ID =
Token. This means even if the transaction is being evaluated to be =
fraudulent afterwards, the OP releases PII to the RP. Depending on the =
way the OP obtained this data, this might have already caused =
unneglectable cost (e.g. for an external commercial claims =
provider).

That=E2=80=99s not the case with PKCE.

We=E2=80=99re talking about confidential clients. =
If the ID Token is not meant for this client then client authentication =
will fail, or else the auth code was meant for this client (but not this =
session) in which case the user already consented to release of PII to =
that RP.

If you are talking about a =
hybrid flow then PKCE doesn=E2=80=99t protect that either. I=E2=80=99d =
like to see encrypted ID tokens become mandatory in hybrid flows, but =
that=E2=80=99s not for this WG.


2) The whole =
check relies on the client. I would rather rely on the OP/AS to enforce =
this security check since clients have a less promising track record of =
implementing security checks. 

3) In mixed OAuth/OIDC scenarios, switching back and force =
between nonce and PKCE does not make developers live simpler. 

Maybe, but I =
don=E2=80=99t think either of these rise to the level of mandating that =
ASes reject non-PKCE requests.

In =
the interests of building consensus, maybe something along the lines of: =
=E2=80=9CAn AS MUST reject requests without a code_challenge from public =
clients, and SHOULD reject such requests from other clients unless there =
is reasonable assurance that the client mitigates these threats in other =
ways=E2=80=9D?

=E2=80=94 =
Neil

=

--Apple-Mail=_C63A8535-4D6E-4D21-8F83-0001088A9B6B--


From nobody Mon May 11 02:24:32 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B26C3A0968 for ; Mon, 11 May 2020 02:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbKFm-z4udjX for ; Mon, 11 May 2020 02:24:28 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312E23A0967 for ; Mon, 11 May 2020 02:24:28 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id w7so9981509wre.13 for ; Mon, 11 May 2020 02:24:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0C6aC4dyUSamJDncRQSwUar5+2uqNdt5qifdcULMZhU=; b=WsTJ9FrA/wUYzK2pgbMJXoIYObXhlZXuR2qHafp7Fbb6QEpYTSXbj5DqsTz/hxO47D 2F8B6ayUQQ8o3FyojKTOsR8YAyTGjMp3e7Q4XCRTLZD+CZRKjnTQ1cMEk7TDt3TyM6f9 QHd9klmuTgCmZdONcb5S0nMb/+6z4dPyB7SS97lV/NQqzHIsJWZrDl1qUKTOirM9Nq+W VklLOREHBV7HE2KkgiCEkaPTNjf4bn8D3/fgQmy+TZWii98Vp00KoMLd2w1xl80IVFIF sZOaEKe7zmHA21BqacIB2hse2t4TiTyEJdFmi+/yZio0wkzLXgBy25pgKDEu5X0EfGI3 WmYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0C6aC4dyUSamJDncRQSwUar5+2uqNdt5qifdcULMZhU=; b=tfx+JWhOdQ5X5oBB7GOIgoqyqoEWgQ5dCXAp0CaG1WhJT26wFxkBvs/aSLHYF47aQJ rxKqN59SS4UHOYBrm3xcWklmDftksFyr4lsB4mnKqEjq5b3SWfVy8sm1NmKFBkChuv8Z Y3n3eQEnAwl9xi9CoVqyYspmTMnfo2wVsrEGtGFpGc2qKr1NhRVXFOm2RWnxaM/RV5GQ f3juhpELj3fpiXy4BZU0uRzFytHyXoIhPjuVoNI2qexFjtEzw5eN53QhoFiUy5VIKwnK WghoujyxcXuzrBFKNPbQKp0ptXQUbev5FbM452hdVUkC2FHHGFCLJlHypCFQllRRcSdy hmtg==
X-Gm-Message-State: AGi0PubspVkTwX5+NFYmYsiCiSkug7k19P/9A76yIsl1BE6fOQxO9MbE VqbElgzkSr+llVXHAIrZCfo+UcFTBwU=
X-Google-Smtp-Source: APiQypLESBFtXh7nKCH0aU4UbNjBa/3Rj55MlPLfOntJsD2P0Bgw5NUAwwCz3QjkTsmEAr6QmAeWYQ==
X-Received: by 2002:adf:8483:: with SMTP id 3mr17915531wrg.206.1589189066487;  Mon, 11 May 2020 02:24:26 -0700 (PDT)
Received: from p200300eb8f301f67ddbc8b7d2a3ed8c7.dip0.t-ipconnect.de (p200300EB8F301F67DDBC8B7D2A3ED8C7.dip0.t-ipconnect.de. [2003:eb:8f30:1f67:ddbc:8b7d:2a3e:d8c7]) by smtp.gmail.com with ESMTPSA id p9sm10539676wrj.29.2020.05.11.02.24.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 02:24:25 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <02581F0B-F4BC-4EBD-860C-3DAFA631BA40@forgerock.com>
Date: Mon, 11 May 2020 11:24:24 +0200
Cc: Dick Hardt , Mike Jones , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F25A8BF-65BD-4066-BF98-AD5900D43BA0@lodderstedt.net>
References:   <8EAF68CC-0094-4BAA-BA47-2A69CD2D3D8A@lodderstedt.net> <02581F0B-F4BC-4EBD-860C-3DAFA631BA40@forgerock.com>
To: Neil Madden 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 09:24:31 -0000

> On 11. May 2020, at 10:59, Neil Madden  =
wrote:
>=20
>=20
>=20
>> On 11 May 2020, at 08:53, Torsten Lodderstedt =
 wrote:
>>=20
>>=20
>>=20
>>> On 11. May 2020, at 09:34, Neil Madden  =
wrote:
>>>=20
>>>=20
>>>=20
>>>> On 11 May 2020, at 08:05, Torsten Lodderstedt =
 wrote:
>>>>=20
>>>> =EF=BB=BF
>>>>=20
>>>>>> On 11. May 2020, at 08:47, Neil Madden =
 wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 11 May 2020, at 07:41, Torsten Lodderstedt =
 wrote:
>>>>>>=20
>>>>>>> On 11. May 2020, at 07:38, Neil Madden =
 wrote:
>>>>>>>=20
>>>>>>> There is no attack that this prevents so your claim of improving =
security is unsubstantiated. I can=E2=80=99t see how we can ship a =
2.1-compliant-by-default AS while this requirement remains so I don=E2=80=99=
t support it.=20
>>>>>>=20
>>>>>> Are you saying PKCE does not prevent any attack?
>>>>>=20
>>>>> No, but servers and clients are already free to support PKCE. =
I=E2=80=99m saying that rejecting requests from non-PKCE clients =
doesn=E2=80=99t prevent any attack. It just denies service to legitimate =
clients.=20
>>>>=20
>>>> There are two aspects to this topic:
>>>>=20
>>>> 1) Do all ASs support PKCE? Requiring PKCE support fosters =
interoperability and security. Security since the client can be sure the =
AS supports PKCE. Today, if the AS does not support PKCE, the client =
will never learn since a compliant AS will just ignore additional =
request parameters.
>>>=20
>>> But just saying that a 2.1 AS MUST support PKCE is enough for this. =
Rejecting requests just to support feature discovery is a sledgehammer =
to crack a nut.=20
>>>=20
>>>>=20
>>>> 2) Do ASs enforce PKCE? This fosters security since it forces =
clients to implement a means against code replay and CSRF.
>>>>=20
>>>=20
>>> Again, just saying that 2.1 clients MUST support PKCE achieves this =
aim. Rejecting non-PKCE requests doesn=E2=80=99t add anything to =
security.=20
>>>=20
>>> And as has been pointed out elsewhere in this thread there are =
clients that don=E2=80=99t benefit from PKCE such as confidential OIDC =
clients. Indeed for most confidential clients the gains of PKCE are =
relatively minor - code injection attacks are already pretty hard to =
pull off in practice against such clients.=20
>>=20
>> I agree, but I wouldn=E2=80=99t say they don=E2=80=99t benefit at =
all.=20
>>=20
>> 1) The nonce check happens after the OP had issued the ID Token. This =
means even if the transaction is being evaluated to be fraudulent =
afterwards, the OP releases PII to the RP. Depending on the way the OP =
obtained this data, this might have already caused unneglectable cost =
(e.g. for an external commercial claims provider).
>>=20
>> That=E2=80=99s not the case with PKCE.
>=20
> We=E2=80=99re talking about confidential clients. If the ID Token is =
not meant for this client then client authentication will fail, or else =
the auth code was meant for this client (but not this session) in which =
case the user already consented to release of PII to that RP.
>=20
> If you are talking about a hybrid flow then PKCE doesn=E2=80=99t =
protect that either.

Sure. The OP won=E2=80=99t issue an ID Token if the PKCE check fails.

> I=E2=80=99d like to see encrypted ID tokens become mandatory in hybrid =
flows, but that=E2=80=99s not for this WG.
>=20
>>=20
>> 2) The whole check relies on the client. I would rather rely on the =
OP/AS to enforce this security check since clients have a less promising =
track record of implementing security checks.=20
>>=20
>> 3) In mixed OAuth/OIDC scenarios, switching back and force between =
nonce and PKCE does not make developers live simpler.=20
>=20
> Maybe, but I don=E2=80=99t think either of these rise to the level of =
mandating that ASes reject non-PKCE requests.
>=20
> In the interests of building consensus, maybe something along the =
lines of: =E2=80=9CAn AS MUST reject requests without a code_challenge =
from public clients, and SHOULD reject such requests from other clients =
unless there is reasonable assurance that the client mitigates these =
threats in other ways=E2=80=9D?

Sounds reasonable.=20

>=20
> =E2=80=94 Neil
>=20


From nobody Mon May 11 03:53:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DF43A0878 for ; Mon, 11 May 2020 03:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL7Jw5TllhOB for ; Mon, 11 May 2020 03:53:08 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EF23A0873 for ; Mon, 11 May 2020 03:53:08 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id w19so3902380wmc.1 for ; Mon, 11 May 2020 03:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=H9ZvwH39ASU34UXQ7dY3VeJbvzltZCKjhgUYA0sV0B0=; b=qm052nZNa4SF3ctPh/IKiCNVeddlWyuLqG4sp4t5RQWNdg1+9yjtkfUAv/9jR4HH5C 81oxvxtWxnJRnnSYwMI4EtfJRh61tWzZLwrSwvL7pUYEeLDM6RhFnXOCJaPftHDnNUPX +5fxKYFh0kcJ9Cq+pRWlwCzetLwuOTeX7rCXbiMkdNtM+PTgoKYHI558aJC/zKnnIqV7 0iEWwQ9kybVkbEZLQPeRnIZnTrCw2W6blhlhxUEvR/rvsmOLx/1mrMaFDX5ShT4MIb3j gtIDcT5JQCVUprx/PGE7O4/1yn94ZDuxwxMtKkpABbMfneq6r2AdpvjV3+CFXGX8Xg1t dMzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=H9ZvwH39ASU34UXQ7dY3VeJbvzltZCKjhgUYA0sV0B0=; b=XzsNLwja7S0y7x6iEwPixpek/yXISEWvMJvKrnaucRMaC6tqYv8bIOunGQ+KjE0PD8 4g2S//TkkhU+h+UdkkzLDO5zqJ0MksQnH/3EyOsmLkl9AEtbjFI/L7V6yG7fjn3ElNgK ePSZYUqzFxCnCCKtnUrPB2AhuAxEUc3pDy3fdSmTQCjt8s/ervQpXJFH7qr2EWEZrJ3G OJcdK5e6nbgJguCtKU432tJwbXx0loQnbVEQuC4tjkPR07OIBVrqZdWteEUSN4bae8/r fVkwZ063DbtN14pHygqcaWU75c4w7Ctiid83K5yxE1/+TzUCzNJi48EpH/ly0S/kOM84 HWQQ==
X-Gm-Message-State: AGi0PuYKUagyjTuyudsmpFZ81SunlpNWPRrmD0Dt7e1+AsZdVvHXW6HY 6Ivp2pakisH0b5GURwRsspbSjWCKT1Mv8UzhznF6tC7pzHc=
X-Google-Smtp-Source: APiQypI7zywuGJQx3mJE3lUGePh9BWDrXo1hDVf6ig/Jv5ERVraxGFZtp55+0oER1YJlo0EORR/NfpDXuc8VOIKgqwo=
X-Received: by 2002:a1c:4d07:: with SMTP id o7mr32883249wmh.59.1589194386431;  Mon, 11 May 2020 03:53:06 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 11 May 2020 06:52:55 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e1e41e05a55d2605"
Archived-At: 
Subject: [OAUTH-WG] New email address
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 10:53:19 -0000

--000000000000e1e41e05a55d2605
Content-Type: text/plain; charset="UTF-8"

All,

I have a new email address *rifaat.s.ietf@gmail.com
* to replace the old address rifaat.ietf@gmail.com.
I did that because some spammers have been sending spam email and
pretending that they are using my old email address as the sender, and as a
result I would get angry replies from the recipients of these spam emails.

Thanks,
 Rifaat

--000000000000e1e41e05a55d2605
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




--000000000000e1e41e05a55d2605--


From nobody Mon May 11 05:34:18 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD33A0953 for ; Mon, 11 May 2020 05:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.414
X-Spam-Level: 
X-Spam-Status: No, score=0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3LQdnHw8Zoo for ; Mon, 11 May 2020 05:34:10 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E398D3A0A64 for ; Mon, 11 May 2020 05:34:08 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d54 with ME id dQa52200i4FMSmm03Qa6E2; Mon, 11 May 2020 14:34:06 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 11 May 2020 14:34:06 +0200
X-ME-IP: 86.238.65.197
To: Benjamin Kaduk 
Cc: Vittorio Bertocci , "oauth@ietf.org" 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu>
From: Denis 
Message-ID: <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>
Date: Mon, 11 May 2020 14:34:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200509005408.GA27494@kduck.mit.edu>
Content-Type: multipart/alternative; boundary="------------37F8BA0FDAC9FA68AB0C0C21"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 12:34:16 -0000

This is a multi-part message in MIME format.
--------------37F8BA0FDAC9FA68AB0C0C21
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Benjamin,

We are making progress since we now understand better each other. You 
wrote several sentences on which I agree:

    "I do in fact agree that token inspection by a client can be useful
    in at least some situations".

    "I fully support having privacy considerations sections that discuss
    the privacy properties of the protocol in question,
    ***e**ven including aspects that are currently lacking*.

    "I do not believe that a JWT profile for OAuth use is the place to
    make changes to the core OAuth protocol that improve its privacy
    properties".

I also accept your apologies.

RFC 6749 is quite clear in section 1.4 that "The string [access token] 
*is usually opaqu**e* to the client".
However, it does not mean that : "The client *MUST NOT* inspect the 
content of the access token".
I believe the wording I proposed corresponds to the reality:

    There is no guarantee that token inspection can always be performed.

When privacy is a concern, if a client wants to verify the claims that 
have been placed into the token but is unable to do it, it will simply 
not present it.

The document should consider more closely the recommendations included  
RFC 6973 (Privacy Considerations for Internet Protocols)
for the writing the Privacy considerations section.

Finally, you wrote:

    Making changes to OAuth that improves its privacy properties is a
    laudable goal, and
    I would happily read any I-Ds that proposed such protocol changes.

Since OAuth has not been constructed from the beginning along Privacy by 
Design rules, it is only possible to make a few improvements.
Whenever possible we should do it.

In my email sent on May the 8 th relative to another thread ( I-D 
Action: draft-ietf-oauth-security-topics-15.txt), I wrote:

    When the token contains one or more attributes that uniquely allow
    to identify the collaborative user (e.g. a "sub" claim),
    then Alice can only impersonate the collaborative user and such a
    case can easily be obtained using TeamViewer.

          * Unfortunately using the "sub" claim is not "privacy
            friendly", since collaborative RSs will be able to link the
            accounts
            of their respective users.  Nevertheless, this a good news
            for Vittorio, since the "sub" claim is REQUIRED in the
            "Profile for OAuth 2.0 Access Tokens". This means that,
            *when this profile is being used, OAuth 2.0 is resistant **to
            the ABC attack*.

          * Using a different claim that would only contain an
            identifier that is unique to the RS (such as a pseudo) would be
            more appropriate (as FIDO does), but I am not aware of a
            claim that has been defined which would have such a semantics.

If a claim that would only contain an identifier that is unique to the 
RS (such as a pseudo) has not already been defined in an I-D,
then it would be interesting to define it.

Denis

> Hi Denis,
>
> Sorry for the slow response.  I had several deadlines this week and
> couldn't think much farther ahead than the next one, so my INBOX fell
> behind.
>
> On Mon, May 04, 2020 at 12:36:05PM +0200, Denis wrote:
>> Hello Benjamin,
>>
>> First of all, you don't need to use an aggressive language to state your
>> opinion.
> I would appreciate a little more clarity on which language comes across as
> "aggressive"; I was trying very hard to stick to what I see as the facts:
>
> - many people are frustrated with these long discussions that continue to
>    rehash similar points and involve people having a hard time seeing each
>    others' worldview
> - you are making proposals for changes to this document that would
>    represent drastic changes from previous specifications that are used by
>    the current document (and are drastic changes from current practice),
>    without acknowledging that they are in fact drastic changes to the core
>    protocol
>
> Please accept my apologies for however I deviated from that goal.
>
> I am trying to get us to a place where we can have productive discussions
> and improve the quality of our protocols.  Right now I don't think we're
> having very productive discussions; in fact, we're holding up progress on a
> document that looks likely to become widely deployed by asking it to do
> more than is reasonable for it to do.
>
>> Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the
>> following title:"IETF Guidelines for Conduct". In particular:
>>
>>      " Regardless of these individual differences, participants treat
>>      their colleagues with respect as persons especially
>>          when it is difficult to agree with them: treat other
>>      participants as you would like to be treated ".
>>
>> I wrote:
>>
>> (...)
>>
>>       I will go one step further: if the client wants to inspect the
>> token and
>>       if the format of the token is unknown to the client, then the client
>> will simply stop its further transmission. For some clients, preserving
>> their
>> privacy may be more important than performing an access to a RS.
>>
>> You responded :
>>
>>      That may be true, but I agree with Vittorio that this document needs to
>>      strongly discourage clients from doing so, since they would
>> be**_breaking _*
>> *_a __protocol invariant_ if they do.
>>
>> If "this may be true", then you should consider that the token
>> inspection by a client may be useful and thus should not be prevented.
> I do in fact agree that token inspection by a client can be useful in at
> least some situations.  However, RFC 6749 is quite clear that "the [access
> token] is usually opaque to the client".  A requirement that the access
> token MUST be inspectable by the client is incompatible with something that
> "is usually opaque to the client".
>
>> However, there is no guarantee that it may always be performed.
> I agree that this is the current state of affairs.
>
>> You are using the wording" _breaking a protocol invariant_". In which
>> RFC (related to OAuth) has such a "protocol invariance" been first
>> mandated ?
> RFC 6749, per above.
>
>> I attempted to find an RFC using the wording "protocol invariant". I
>> found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1
>> with the topic " Declaring Protocol Invariants", using the following terms:
>>
>> Declaring a protocol's invariants represents a promise made by the
>> protocol's developers that certain bits in the wire image, and behaviors
>>      observable in the wire image, will be preserved through the
>> specification of all future versions of the protocol.
> Perhaps my usage of the term "protocol invariant" was confusing or
> inappropriate.  I meant to say that you are trying to change a property of
> the core protocol specification; whether or not it is best described as an
> "invariant" is immaterial to my point.  In other words, a generic OAuth 2.0
> client has to be prepared to deal with access tokens that are opaque to it.
>
>> Using these explanations, I have difficulties to understand how
>> preventing the content of a JWT to be inspected by a client may be
>> considered
>> as "a promise made by the protocol's developers that certain bits in the
>> wire, and behaviors observable in the wire, will be preserved
>> through the specification of all future versions of the protocol".
>>
>> I probably missed something. Would you be able to explain ?
> (I tried to above.)
>
>> A second point:
>>
>> As a co-author of RFC 3161 published in August 2001 and of RFC 36268
>> published in November 2003 to name a few of the RFCs
>> to which I contributed, I am not aware of any reference to an ISO
>> document made into a RFC. This seems to be a common practice.
>> When I used the term "refer", I was not asking to place a reference to
>> an ISO document in this working draft but to allow everybody in
>> the WG to have the ability to have a look at its content (and for free).
> Ah, I misunderstood you then; sorry about that.
> Using readily-available documents where someone has already written down
> relevant information is a great way to quick-start a discussion, but I
> thought you wanted us to have this I-D accept wholesale the definitions
> from the ISO document without further discussion.
>
>> Table 3 is simply a quick "reference" to ten privacy principles.
>>
>> A third point:
>>
>> RFC 6973 (Privacy Considerations for Internet Protocols) has been
>> published in July 2013. Its introduction mentions:
>>
>> The guidance provided here can and should be used to _assess the privacy
>> considerations of protocol_, architectural,
>>       and operational _specifications_ (...)
>>
>>      The guidance provided here is meant to help the thought process of
>> privacy analysis; it does not provide specific directions
>>       for how to write a privacy considerations section.
>>
>> Section 7 (Guidelines) mentions :
>>
>>      This section provides guidance for document authors in the form of a
>> questionnaire about a protocol being designed.
>>      The questionnaire may be useful at any point in the design process,
>> particularly after document authors have developed
>>      a high-level protocol model as described in [RFC4101].
>> (...)
>> However, by carefully considering the answers to each question, document
>> authors should be able to produce a comprehensive
>>      analysis that can serve as the basis for discussion of whether the
>> protocol adequately protects against privacy threats.
> I actually think it would be quite valuable to perform this kind of
> analysis for RFC 6749 (and extensions).  Its usage has evolved quite a lot
> from its initial origins, and there are (as you have pointed out) many
> areas that are lacking.  Would you be willing to start an I-D on this
> topic?  I think that it would be more valuable to do something systematic
> than to try to do something piecemeal for this document just because it is
> a document the WG is currently working on.
>
>> An important item which is addressed both in ISO 29100 and RFC 6973 in
>> section 7.1 is "Data Minimization". RFC 6973 mentions:
>>
>> a.*Identifiers*.What identifiers does the protocol use for
>> distinguishing initiators of communications?
>> Does the protocol use identifiers that allow different protocol
>> interactions to be correlated?
>> What identifiers could be omitted or be made less identifying while
>> still fulfilling the protocol’s goals?
>>
>> b.*Data*.What information does the protocol expose about individuals,
>> their devices, and/or their device usage (other than the identifiers
>> discussed in (a))?
>>        To what extent is this information linked to the identities of the
>> individuals?How does the protocol combine personal data with the
>> identifiers discussed in (a)?
>>
>> c.*Observers*.Which information discussed in (a) and (b) is exposed to
>> each other protocol entity (i.e., recipients, intermediaries, and enablers)?
>> Are there ways for protocol implementers to choose to limit the
>> information shared with each entity?  µ
>> Are there operational controls available to limit the information shared
>> with each entity?
>> (...)
>>
>> e.*Persistence of identifiers*.What assumptions are made in the protocol
>> design about the lifetime of the identifiers discussed in (a)?
>>        Does the protocol allow implementers or users to delete or replace
>> identifiers?
>>
>> f.*Correlation*.Does the protocol allow for correlation of
>> identifiers?Are there expected ways that information exposed by the
>> protocol will be combined
>>       or correlated with information obtained outside the protocol?
>>
>> RFC 6973 also mentions in section 7.2 (User Participation) (while ISO
>> 29100 uses the wording "Consent and choice"):
>>
>> a.*User control*.What controls or consent mechanisms does the protocol
>> define or require before personal data or identifiers are shared or
>> exposed via the protocol?
>>
>>
>> All the above questions are useful to assess privacy considerations
>> about the protocol. Some key questions related to OAuth are the following:
>>
>>    * considering the current semantics of the "sub" claim, what are the
>>      implications in terms of "correlation" ?
>>    * considering the current semantics of the scope request parameter (or
>>      of any other token request parameter), what are the implications in
>>      terms of "user control" ?
> I agree: these are "key questions related to OAuth".  Where I perhaps
> disagree with you is that I believe they are key questions relating to the
> protocol as a whole; the discussion so far seems to indicate that you wish
> to both perform this analysis and change the protocol all as part of the
> JWT profile document.  I think the tasks are better performed separately.
>
>> The next version of this document should use RFC 6973 more closely as a
>> guidance to "_assess the privacy considerations __of the protocol_ and
>> of operational _specifications_".
> I fully support having privacy considerations sections that discuss the
> privacy properties of the protocol in question, even including aspects that
> are currently lacking.
>
> However, I do not believe that a JWT profile for OAuth use is the place to
> make changes to the core OAuth protocol that improve its privacy properties.
> (If we can specify the token format in a way has better privacy properties
> than alternative token formats, we should, of course, but we can't change
> the protocol itself.)
> Making changes to OAuth that improves its privacy properties is a laudable
> goal, and I would happily read any I-Ds that proposed such protocol changes
> (though I fear that the current deployment/semantics may constrain the
> degree to which OAuth 2.0 can be improved and have much more hope for the
> txauth group to produce a protocol with good privacy properties).  The
> discussion so far has not convinced me that this document is the right
> document in which to do so.
>
> Thanks,
>
> Ben
>
>>> Hi Denis,
>>>
>>> You seem to be continuing to be operating under incorrect assuptions about
>>> how OAuth 2.0 works, and have proceeded to make long chains of reasoning
>>> that, unfortunately, are not based on a solid foundation.  In order to
>>> reduce the amount of frustration amongst all participants, in the future I
>>> strongly suggest that you make sure you have the fundamentals correct
>>> before going into long chains of reasoning.
>>>
>>> Furthermore, while you have indeed identified some areas where the current
>>> OAuth ecosystem could be improved, I reiterate that the current document,
>>> defining a token format that is optional to use, is not the place to make
>>> changes to how OAuth works.  I think you do everyone a disservice for
>>> attempting to suggest that this document should do so.
>>>
>>> Because there is so much based on a flawed foundation, I will not respond
>>> inline to every point, but do see a few things where further clarification
>>> would be useful.
>>>
>>> On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
>>>> Hello Vittorio,
>>>>
>>>> Your reply was amazingly fast. Responses are between the lines.
>>>>
>>>>> Thanks Denis for the thorough commentary.
>>>>>
>>>>> /> The title of this spec./
>>>>>
>>>>> Fixed, thanks!
>>>>>
>>>>> /> The client MUST NOT inspect the content of the access token/
>>>>>
>>>>>
>>>>> This is really a sticky point. I really want to acknowledge your PoV
>>>>> on this, but at the same time I found this to be one of the biggest
>>>>> sources of issues
>>>>> in the use of JWT for access tokens hence I feel we really need to
>>>>> give solid guidance here. Let me expand further on the reasoning
>>>>> behind it,
>>>>> and perhaps we can get to language that satisfies both PoVs.
>>>>>
>>>>>
>>>>> To me the key point is that clients should not write /code/ that
>>>>> inspects access tokens. Taking a dependency on the ability to do so is
>>>>> ignoring fundamental information
>>>>> about the architecture and relationships between OAuth roles, and
>>>>> suggests an ability of the client to understand the semantic of the
>>>>> content that cannot be assumed
>>>>> in the general case. I expanded on the details in my former reply to
>>>>> you on this topic, I would recommend referring to it.
>>>>>
>>>>> Clients violating this simple principle has been one of the most
>>>>> common sources of production issues I had to deal with in the past few
>>>>> years, and one of the hardest
>>>>> to remediate given that clients are hard to update and sometimes the
>>>>> things they relied on were irremediably lost. This is why I am
>>>>> inclined to put in here strong language.
>>>>>
>>>>> That said: I have nothing against client developers examining a
>>>>> network trace and drawing conclusions based on the content of what
>>>>> they see. That doesn’t create any hard
>>>>> dependencies and has no implications in respect to changes in the
>>>>> solution behavior. However I am not sure how to phrase that in the
>>>>> specification, given that referring
>>>>> to the client inevitably refers to its code. I am open to suggestions.
>>>>>
>>>> First of all, a "*MUST NOT* "should not be placed in a privacy
>>>> considerations section, but in the main body of the document.
>>>> The goal of a privacy considerations section is to provide explanations,
>>>> but not to introduce additional requirements.
>>> That's not actually a requirement.  In many cases it makes sense to avoid
>>> putting normative requirements in the security and/or privacy
>>> considerations sections, but it is very much a thing that is done in many
>>> RFCs, and in some cases it is useful to do so.
>>>
>>>> Then after, since this section is about privacy considerations, it is
>>>> important to refer to an ISO standard that has been published 9 years ago.
>>> Is it?  I don't see much precedent for IETF documents referencing this ISO
>>> standard.  If it's so important you'd think that we'd have been citing it
>>> with regularity.  Since this will be the first or second time, I think you
>>> need to provide some additional justification as to how the topics it
>>> covers fit within the existing IETF BCPs for how we treat security and
>>> privacy considerations before we conclude that it is the appropriate
>>> reference.
>>>
>>>> It is ISO 29100 (Information technology — Security techniques — Privacy
>>>> framework). Most of the ISO standards need to be bought.
>>>> However, there are a few exceptions and this standard can be freely
>>>> downloaded from the ISO web site, if you accept some conditions,
>>>> using this URL:
>>>>
>>>>       https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
>>>>
>>>> ISO 29100, even if it is outdated on some aspects (it only deals with
>>>> two entities), identifies ten principles (See Table 3).
>>>>
>>>>       1. Consent and choice
>>>>
>>>>       2. Purpose legitimacy and specification
>>>>
>>>>       3. Collection limitation
>>>>
>>>>       4. Data minimization
>>>>
>>>>       5. Use, retention and disclosure limitation
>>>>
>>>>       6. Accuracy and quality
>>>>
>>>>       7. Openness, transparency and notice
>>>>
>>>>       8. Individual participation and access
>>>>
>>>>       9. Accountability
>>>>
>>>>       10. Information security
>>>>
>>>>       11. Privacy compliance
>>>>
>>>> If the client is unable to inspect the token, then openness and
>>>> transparency do not exist any more.
>>>>
>>>> Since there is no formal protocol in OAuth 2.0  for "consent and
>>>> choice", the only way for a client for denying its consent is to inspect
>>>> the token
>>>> and to stop its transmission if the content of the token is not
>>>> considered to be adequate for it.
>>>>
>>>> Since you are open to suggestions, would you please reconsider the text
>>>> I proposed: it simply states that if the client wants to inspect the token,
>>>> it will not necessarily be in a position to do it. It is simply a
>>>> warning, but this warning does not prevent the client to attempt to
>>>> inspect the token .
>>>>
>>>> I will go one step further: if the client wants to inspect the token and
>>>> if the format of the token is unknown to the client, then the client
>>>> will simply
>>>> stop its further transmission. For some clients, preserving their
>>>> privacy may be more important than performing an access to a RS.
>>> That may be true, but I agree with Vittorio that this document needs to
>>> strongly discourage clients from doing so, since they would be breaking a
>>> protocol invariant if they do.
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>>>>>    3)…
>>>>> I have a pretty hard time following the chain of reasoning in this
>>>>> section. Let me attempt to tackle it to the best of my understanding.
>>>>>
>>>>> I think the key might be
>>>>>
>>>>> /> a client should be able to choose whether it wishes the sub claim
>>>>> to contain [..]
>>>>>
>>>>> /
>>>>>
>>>>> I don’t think that should be a choice left to the client. In business
>>>>> systems, my experience is that the type of identifiers to be used
>>>>> (when the IdP gives any choice at all)
>>>>>    is established at resource provisioning time. I am not aware of
>>>>> mechanisms thru which a client signals the nature of the identifier to
>>>>> be used, nor that would be fully
>>>>> feasible (the resource knows what it needs to perform its function).
>>>>>
>>>> Consent and choice is the first of the ten privacy principles. Since
>>>> OAuth has not been constructed taking into considerations this privacy
>>>> principle,
>>>> it is quite "normal" that you don't observe protocols able to do it at
>>>> the present time.
>>>>
>>>>> Furthermore:
>>>>>
>>>>> /> which has nothing to do with uniqueness since the value changes for
>>>>> every generated token.
>>>>>
>>>>> /
>>>>>
>>>>> Again, this is something that was touched on in my former reply to
>>>>> your message. As long as an identifier identifies one resource only,
>>>>> it satisfies uniqueness. It doesn’t have to be a singleton.
>>>>>
>>>> It is a matter of interpretation. I stick to the definition given in RFC
>>>> 7519 (section 4.1.2):
>>>>
>>>> *T**he subject value MUST either be scoped to be locally unique in the
>>>> context of the issuer or be globally unique.*
>>>>
>>>> However, the "context of the issuer" is left undefined.
>>>>
>>>>> Finally, the scope is optional (for good reasons: 1^st party and non
>>>>> delegation scenarios don’t require it) hence it cannot be relied upon
>>>>> for properties that should hold in every scenario.
>>>>>
>>>> I would not say that the scope request parameter is a nice way to choose
>>>> which attributes should be placed in a JWT. However, considering the
>>>> limitations placed
>>>> in this document, it is the ONLY way to do. In my email sent before the
>>>> virtual meeting, I wrote: "Allowing a client to only specify a scope and
>>>> a resource is very restrictive".
>>>>
>>>> Clause 2.2.2 (second paragraph) states:
>>>>
>>>> ***This profile does not introduce any mechanism for a client to**
>>>> ******directly request the presence of specific claims in JWT access**
>>>> ******tokens*, as the authorization server can determine what additional
>>>> claims are required by a particular resource server by taking in
>>>> consideration the client_id of the client, the scope and the resource
>>>> parameters included in the request.
>>>>
>>>> Currently, the client has no control of the claims that will be placed
>>>> in a JWT and further more the current wording of privacy consideration
>>>> section
>>>> prevents the client to have any inspection of the attributes that have
>>>> been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not
>>>> fulfilled.
>>>>
>>>> There are more implications. If, in the future, a mechanism is defined
>>>> to allow the client to choose the type of the attributes that should be
>>>> placed in a JWT,
>>>> then the "sub" claim is insufficient. Taking into consideration my
>>>> previous email, four types of attributes types would need to be specified:
>>>>
>>>> The client should be able to choose whether it wishes a claim that contains:
>>>>
>>>>     *      a global unique identifier for all ASs ("globally unique"),
>>>>     *      a unique identifier for each AS ("locally unique in the context
>>>>       of the issuer"),
>>>>     *      a different pseudonym for each RS, or
>>>>     *      a different pseudonym for each authorization token request.
>>>>
>>>> Clause 2.2.2 states:
>>>>
>>>> *   the authorization server can determine what additional**
>>>> ******claims are required by a particular resource server* by taking in
>>>> consideration the client_id of the client, the scope and the resource
>>>> parameters included in the request.
>>>>
>>>> I don't believe this is true in general. Considering its privacy
>>>> preferences, only the client may know what is appropriate: not the AS,
>>>> neither the RS.
>>>>
>>>>> In summary: per the preceding thread on this topic, the consensus was
>>>>> that varying the sub content was a satisfactory way of protecting
>>>>> against correlation.
>>>>>
>>>> "/if all you have is a hammer, everything looks like a nail/".
>>>>
>>>> When the only parameter that can be used is the "sub" claim, then the
>>>> only solution is to place everything into it.
>>>>
>>>>> I don’t a gree that clients should have a mechanism to request
>>>>> different sub flavors, as that decision should be done out of band by
>>>>> the AS and RS; and the scope isn’t always available anyway.
>>>>>
>>>> While it would be nice to have such a mechanism, we are not going to
>>>> define such a mechanism during a second WGLC.
>>>>
>>>> The privacy considerations section should only inform the readers about
>>>> the limitations of the protocol in terms of privacy.
>>>> I have proposed text to address the point. If you would prefer a
>>>> different wording to address this point, please make another proposal.
>>>>
>>>>> /> targeting of access tokens/
>>>>>
>>>>> Let me think about that a bit longer.
>>>>>
>>>>> I acknowledge that the decision of including an audience has the
>>>>> effect of letting the AS track when the client accesses a particular
>>>>> resource,
>>>>> but at the same time that’s completely mainstream and very much by
>>>>> design in a very large number of cases. As such, I find the language
>>>>> you are suggesting to be potentially confusing, as it positions this
>>>>> as an exception vs a privacy protecting mainstream that is in fact not
>>>>> common,
>>>>> and ascribes to the client more latitude than I believe is legitimate
>>>>> to expect or grant.
>>>>>
>>>>> I’ll try to come up with concise language that clarifies to the reader
>>>>> that the current mechanism does allow AS tracking.
>>>>>
>>>> Please do so.
>>>>
>>>> Denis
>>>>
>>>>> *From: *OAuth  on behalf of Denis
>>>>> 
>>>>> *Date: *Wednesday, April 29, 2020 at 09:12
>>>>> *To: *"oauth@ietf.org" 
>>>>> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
>>>>> for OAuth 2.0 Access Tokens"
>>>>>
>>>>> You will find four comments numbered 1) to 4).
>>>>>
>>>>> *1) *The title of this spec. is:
>>>>>
>>>>> JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
>>>>>
>>>>> So, this spec. is supposed to be targeted to OAuth *2.0. * However,
>>>>> the header at the top of the page omits to mention it.
>>>>>
>>>>> Currently, it is :
>>>>>
>>>>> Internet-Draft OAuth Access Token JWT Profile           April 2020
>>>>>
>>>>> It should rather be:
>>>>>
>>>>> Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020
>>>>>
>>>>> *2)* The following text is within section 6.
>>>>>
>>>>> The client MUST NOT inspect the content of
>>>>> the access token: the authorization server and the resource server
>>>>> might decide to change token format at any time (for example by
>>>>> switching from this profile to opaque tokens) hence any logic in the
>>>>> client relying on the ability to read the access token content would
>>>>> break without recourse.
>>>>> Nonetheless, authorization servers should
>>>>> not assume that clients will comply with the above.
>>>>>
>>>>> It is of a primary importance that clients MAY be able to inspect
>>>>> tokens before transmitting them.
>>>>> The "MUST NOT" is not acceptable.
>>>>>
>>>>> The above text should be replaced with:
>>>>>
>>>>> Reading the access token content may be useful for the user to verify
>>>>> that
>>>>> the access token content matches with its expectations. However,
>>>>> the authorization server and the resource server might decide to
>>>>> change the
>>>>> token format at any time.  Thus, the client should not expect to
>>>>> always be
>>>>> in a position to read the access token content.
>>>>>
>>>>> The remaining of the text about this topic is fine.
>>>>>
>>>>>
>>>>> *3) *The next topic is about the sub claim.
>>>>>
>>>>> The text states:
>>>>>
>>>>> Although the ability to correlate requests might be required by
>>>>> design in many scenarios, there are scenarios where the authorization
>>>>> server might want to prevent correlation to preserve the desired
>>>>> level of privacy. Authorization servers should choose how to assign
>>>>> sub values according to the level of privacy required by each
>>>>> situation.
>>>>>
>>>>> I have a set of questions:
>>>>>
>>>>>    1. How can authorization servers choose how to assign sub values
>>>>>       according to the level of privacy required "by each situation" ?
>>>>>    2. How can authorization servers know the level of privacy required
>>>>>       "by each situation" ?
>>>>>    3. How can the users be informed of the level of privacy required "by
>>>>>       each situation" ?
>>>>>    4. How can the users *consent* with the level of privacy required "by
>>>>>       each situation" ?
>>>>>
>>>>> Currently, the request MUST include either a resource parameter or an
>>>>> aud claim parameter, while it MAY include a scope parameter.
>>>>>
>>>>> The syntax of the scope parameter is a list of space-delimited,
>>>>> case-sensitive strings (RFC 6749). It is thus subject to private
>>>>> agreements
>>>>> between clients and Authorization Servers. Since the scope is being
>>>>> returned, it is a primary importance that the returned scope matches
>>>>> with its expectations before transmitting the token to a Resource Server.
>>>>>
>>>>> In theory, a client should be able to choose whether it wishes the sub
>>>>> claim to contain :
>>>>>
>>>>>     * a global unique identifier for all ASs ("globally unique"),
>>>>>     * a unique identifier for each AS ("locally unique in the context of
>>>>>       the issuer"),
>>>>>     * a different pseudonym for each RS, or
>>>>>     * a different pseudonym for each authorization token request.
>>>>>
>>>>> The only variable parameter that it can use for this purpose in the
>>>>> token request is the scope parameter.
>>>>>
>>>>> RFC 7519 states is section 4.1.2:
>>>>>
>>>>> The subject value MUST either be scoped to be locally unique in the
>>>>> context of the issuer
>>>>> or be globally unique.
>>>>>
>>>>> It is quite hard to recognize that the sub claim is able to carry a
>>>>> different pseudonym for each RS, i.e. for case (c), or
>>>>> a different pseudonym for each authorization token request, i.e. for
>>>>> case (d), which has nothing to do with uniqueness
>>>>> since the value changes for every generated token.
>>>>>
>>>>> This has implications about the following text:
>>>>>
>>>>> For instance: if a solution requires preventing tracking
>>>>> principal activities across multiple resource servers, the
>>>>> authorization server should ensure that JWT access tokens meant for
>>>>> different resource servers have distinct sub values that cannot be
>>>>> correlated in the event of resource servers collusion.
>>>>>
>>>>> Since it addresses case (c).
>>>>>
>>>>> and also about the following text:
>>>>>
>>>>> 4.b) Similarly: if a solution requires preventing a resource server from
>>>>> correlating the principal’s activity within the resource itself, the
>>>>> authorization server should assign different sub values for every JWT
>>>>> access token issued.
>>>>>
>>>>> Since it addresses case (d).
>>>>>
>>>>> This means that the current text placed in the privacy considerations
>>>>> section was a good attempt to address the case,
>>>>> but that the text needs to be revised.
>>>>>
>>>>> Proposed text replacement for all the previously quoted sentences:
>>>>>
>>>>> According to RFC 7519 (4.1.2): The subject value MUST either be scoped
>>>>> to be locally unique in the context of the issuer or be globally unique.
>>>>>
>>>>> When the sub claim contains a globally unique identifier, this allows
>>>>> to correlate principal activities across multiple resource servers,
>>>>> while in addition,
>>>>> this globally unique identifier may also allow to correlate the
>>>>> principal activities on servers where no access has been performed by
>>>>> the principals
>>>>> to these servers but where the same globally unique identifiers are
>>>>> being used by these servers.
>>>>>
>>>>> When the sub claim contains a locally unique identifier in the context
>>>>> of the issuer, this also allows the tracking of principal activities
>>>>> across multiple resource servers.
>>>>>
>>>>> The scope request parameter is the only way to influence on the
>>>>> content of the sub claim parameter. Its meaning is subject to a
>>>>> private agreement
>>>>> between the client and the AS, which means that the use of the scope
>>>>> parameter is the only way to choose between a locally unique identifier
>>>>> in the context of the issuer or a globally unique identifier.
>>>>>
>>>>> Since the scope parameter is being returned, it is a primary
>>>>> importance that the returned scope matches with the expectations of
>>>>> the client before transmitting
>>>>> the token to a Resource Server.
>>>>>
>>>>> However, there are other cases where the client would like to be able
>>>>> to choose whether it wishes the sub claim to contain :
>>>>>       - a different pseudonym for each RS so that different resource
>>>>> servers will be unable to correlate its activities, or
>>>>>       - a different pseudonym for each authorization token request, so
>>>>> that the same resource server cannot correlate its activities
>>>>> performed at different instant of time.
>>>>>
>>>>> Considering the semantics of the sub claim, these two cases cannot be
>>>>> currently supported.
>>>>>
>>>>>
>>>>> *4) *The next topic is about the targeting of access tokens
>>>>>
>>>>> Text had been proposed before the last conference call. Then, the
>>>>> topic has been presented at the very end of the last conference call,
>>>>> but no text has been included
>>>>> in the next draft.
>>>>>
>>>>> Here is a revised text be included in the privacy considerations section:
>>>>>
>>>>> For security reasons, some clients may be willing to target their
>>>>> access tokens but, for privacy reasons, may be unwilling to disclose
>>>>> to Authorization Servers
>>>>> an identification of the Resource Servers they are going to access, so
>>>>> that Authorization Servers will be unable to know which resources
>>>>> servers are being accessed.
>>>>> The disclosure of the Resource Servers names allows the Authorization
>>>>> Servers to list all the Resource Servers being access by all its users
>>>>> and in addition to list pairs
>>>>> of (Principal, Resource Servers) which allow to trace all the users
>>>>> accesses to Resource Servers performed through a given Authorization
>>>>> Server. When a token is targeted,
>>>>> this profile does not contain provisions to address these two threats.
>>>>>
>>>>> Denis
>>>>>
>>>>>       Hi all,
>>>>>
>>>>>       This is a second working group last call for "JSON Web Token (JWT)
>>>>>       Profile for OAuth 2.0 Access Tokens".
>>>>>
>>>>>       Here is the document:
>>>>>
>>>>>       https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>>>>>
>>>>>       Please send your comments to the OAuth mailing list by April 29, 2020.
>>>>>
>>>>>       Regards,
>>>>>
>>>>>        Rifaat & 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
>>


--------------37F8BA0FDAC9FA68AB0C0C21
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Benjamin,

    


    

    
We are making progress since we now
      understand better each other. You wrote several sentences on which
      I agree:

    

      
"I do in fact agree that token
        inspection by a client can be useful in at least some
        situations".
      

      


      

      
"I fully support having privacy
        considerations sections that discuss the privacy properties of
        the protocol in question,

          even including aspects that
          are currently lacking.

      


        "I do not believe that a JWT profile for OAuth use is the place
        to make changes to the core OAuth protocol that improve its
        privacy properties".

    

    
I also accept your apologies.

    


    

    
RFC 6749 is quite clear in section 1.4
      that "The string [access token] is usually opaque
      to the client". 

      However, it does not mean that : "The client MUST NOT
      inspect the content of the access token".

    
I believe the wording I proposed
      corresponds to the reality: 

    

    

      
There is no guarantee that token
        inspection can always be performed.

    

    
When privacy is a concern, if a client
      wants to verify the claims that have been placed into the token
      but is unable to do it, it will simply not present it. 

    

    


    

    
The document should consider more
      closely the recommendations included  RFC 6973 (Privacy
      Considerations for Internet Protocols) 

      for the writing the Privacy considerations section.

    


    

    
Finally, you wrote: 

    

    

      
Making changes to OAuth that improves
        its privacy properties is a laudable goal, and 

        I would happily read any I-Ds that proposed such protocol
        changes.

    

    
Since OAuth has not been constructed
      from the beginning along Privacy by Design rules, it is only
      possible to make a few improvements. 

      Whenever possible we should do it. 

    

    

    
In my email sent on May the 8 th
      relative to another thread ( I-D Action:
      draft-ietf-oauth-security-topics-15.txt), I wrote:

    

      

        
When the token contains one or more attributes that uniquely
          allow to identify the collaborative user (e.g. a "sub" claim),
          

          then Alice can only impersonate the collaborative user and
          such a case can easily be obtained using TeamViewer.

        

      

      

        

          
    
            
  • Unfortunately using the "sub" claim is not "privacy
              friendly", since collaborative RSs will be able to link
              the accounts 
    
              of their respective users.  Nevertheless, this a good news
              for Vittorio, since the "sub" claim is REQUIRED in the 
    
              "Profile for OAuth 2.0 Access Tokens". This means that, when
                this profile is being used, OAuth 2.0 is resistant to
                
    
                the ABC attack    . 
    
              
    
            
    • 
            
  • Using a different claim that would only contain an
              identifier that is unique to the RS (such as a pseudo)
              would be
    
              more appropriate (as FIDO does), but I am not aware of a
              claim that has been defined which would have such a
              semantics.
    • 
          

        

      

      If a claim that would only contain an identifier that is unique to
      the RS (such as a pseudo) has not already been defined in an I-D,
      

      then it would be interesting to define it.

    


    

    
Denis

    

    

      
Hi Denis,

Sorry for the slow response.  I had several deadlines this week and
couldn't think much farther ahead than the next one, so my INBOX fell
behind.

On Mon, May 04, 2020 at 12:36:05PM +0200, Denis wrote:


      

        
Hello Benjamin,

First of all, you don't need to use an aggressive language to state your 
opinion.


      

      
I would appreciate a little more clarity on which language comes across as
"aggressive"; I was trying very hard to stick to what I see as the facts:

- many people are frustrated with these long discussions that continue to
  rehash similar points and involve people having a hard time seeing each
  others' worldview
- you are making proposals for changes to this document that would
  represent drastic changes from previous specifications that are used by
  the current document (and are drastic changes from current practice),
  without acknowledging that they are in fact drastic changes to the core
  protocol

Please accept my apologies for however I deviated from that goal.

I am trying to get us to a place where we can have productive discussions
and improve the quality of our protocols.  Right now I don't think we're
having very productive discussions; in fact, we're holding up progress on a
document that looks likely to become widely deployed by asking it to do
more than is reasonable for it to do.



      

        
Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the 
following title:"IETF Guidelines for Conduct". In particular:

    " Regardless of these individual differences, participants treat
    their colleagues with respect as persons especially
        when it is difficult to agree with them: treat other
    participants as you would like to be treated ".

I wrote:

(...)

     I will go one step further: if the client wants to inspect the 
token and
     if the format of the token is unknown to the client, then the client
will simply stop its further transmission. For some clients, preserving 
their
privacy may be more important than performing an access to a RS.

You responded :

    That may be true, but I agree with Vittorio that this document needs to
    strongly discourage clients from doing so, since they would 
be**_breaking _*
*_a __protocol invariant_ if they do.

If "this may be true", then you should consider that the token 
inspection by a client may be useful and thus should not be prevented.


      

      
I do in fact agree that token inspection by a client can be useful in at
least some situations.  However, RFC 6749 is quite clear that "the [access
token] is usually opaque to the client".  A requirement that the access
token MUST be inspectable by the client is incompatible with something that
"is usually opaque to the client".



      

        
However, there is no guarantee that it may always be performed.


      

      
I agree that this is the current state of affairs.



      

        
You are using the wording" _breaking a protocol invariant_". In which 
RFC (related to OAuth) has such a "protocol invariance" been first 
mandated ?


      

      
RFC 6749, per above.



      

        
I attempted to find an RFC using the wording "protocol invariant". I 
found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1
with the topic " Declaring Protocol Invariants", using the following terms:

Declaring a protocol's invariants represents a promise made by the 
protocol's developers that certain bits in the wire image, and behaviors
    observable in the wire image, will be preserved through the 
specification of all future versions of the protocol.


      

      
Perhaps my usage of the term "protocol invariant" was confusing or
inappropriate.  I meant to say that you are trying to change a property of
the core protocol specification; whether or not it is best described as an
"invariant" is immaterial to my point.  In other words, a generic OAuth 2.0
client has to be prepared to deal with access tokens that are opaque to it.



      

        
Using these explanations, I have difficulties to understand how 
preventing the content of a JWT to be inspected by a client may be 
considered
as "a promise made by the protocol's developers that certain bits in the 
wire, and behaviors observable in the wire, will be preserved
through the specification of all future versions of the protocol".

I probably missed something. Would you be able to explain ?


      

      
(I tried to above.)



      

        
A second point:

As a co-author of RFC 3161 published in August 2001 and of RFC 36268 
published in November 2003 to name a few of the RFCs
to which I contributed, I am not aware of any reference to an ISO 
document made into a RFC. This seems to be a common practice.
When I used the term "refer", I was not asking to place a reference to 
an ISO document in this working draft but to allow everybody in
the WG to have the ability to have a look at its content (and for free). 


      

      
Ah, I misunderstood you then; sorry about that.
Using readily-available documents where someone has already written down
relevant information is a great way to quick-start a discussion, but I
thought you wanted us to have this I-D accept wholesale the definitions
from the ISO document without further discussion.



      

        
Table 3 is simply a quick "reference" to ten privacy principles.

A third point:

RFC 6973 (Privacy Considerations for Internet Protocols) has been 
published in July 2013. Its introduction mentions:

The guidance provided here can and should be used to _assess the privacy 
considerations of protocol_, architectural,
     and operational _specifications_ (...)

    The guidance provided here is meant to help the thought process of 
privacy analysis; it does not provide specific directions
     for how to write a privacy considerations section.

Section 7 (Guidelines) mentions :

    This section provides guidance for document authors in the form of a 
questionnaire about a protocol being designed.
    The questionnaire may be useful at any point in the design process, 
particularly after document authors have developed
    a high-level protocol model as described in [RFC4101].
(...)
However, by carefully considering the answers to each question, document 
authors should be able to produce a comprehensive
    analysis that can serve as the basis for discussion of whether the 
protocol adequately protects against privacy threats.


      

      
I actually think it would be quite valuable to perform this kind of
analysis for RFC 6749 (and extensions).  Its usage has evolved quite a lot
from its initial origins, and there are (as you have pointed out) many
areas that are lacking.  Would you be willing to start an I-D on this
topic?  I think that it would be more valuable to do something systematic
than to try to do something piecemeal for this document just because it is
a document the WG is currently working on.



      

        
An important item which is addressed both in ISO 29100 and RFC 6973 in 
section 7.1 is "Data Minimization". RFC 6973 mentions:

a.*Identifiers*.What identifiers does the protocol use for 
distinguishing initiators of communications?
Does the protocol use identifiers that allow different protocol 
interactions to be correlated?
What identifiers could be omitted or be made less identifying while 
still fulfilling the protocol’s goals?

b.*Data*.What information does the protocol expose about individuals, 
their devices, and/or their device usage (other than the identifiers 
discussed in (a))?
      To what extent is this information linked to the identities of the 
individuals?How does the protocol combine personal data with the 
identifiers discussed in (a)?

c.*Observers*.Which information discussed in (a) and (b) is exposed to 
each other protocol entity (i.e., recipients, intermediaries, and enablers)?
Are there ways for protocol implementers to choose to limit the 
information shared with each entity?  µ
Are there operational controls available to limit the information shared 
with each entity?
(...)

e.*Persistence of identifiers*.What assumptions are made in the protocol 
design about the lifetime of the identifiers discussed in (a)?
      Does the protocol allow implementers or users to delete or replace 
identifiers?

f.*Correlation*.Does the protocol allow for correlation of 
identifiers?Are there expected ways that information exposed by the 
protocol will be combined
     or correlated with information obtained outside the protocol?

RFC 6973 also mentions in section 7.2 (User Participation) (while ISO 
29100 uses the wording "Consent and choice"):

a.*User control*.What controls or consent mechanisms does the protocol 
define or require before personal data or identifiers are shared or 
exposed via the protocol?


All the above questions are useful to assess privacy considerations 
about the protocol. Some key questions related to OAuth are the following:

  * considering the current semantics of the "sub" claim, what are the
    implications in terms of "correlation" ?
  * considering the current semantics of the scope request parameter (or
    of any other token request parameter), what are the implications in
    terms of "user control" ?


      

      
I agree: these are "key questions related to OAuth".  Where I perhaps
disagree with you is that I believe they are key questions relating to the
protocol as a whole; the discussion so far seems to indicate that you wish
to both perform this analysis and change the protocol all as part of the
JWT profile document.  I think the tasks are better performed separately.



      

        
The next version of this document should use RFC 6973 more closely as a 
guidance to "_assess the privacy considerations __of the protocol_ and 
of operational _specifications_".


      

      
I fully support having privacy considerations sections that discuss the
privacy properties of the protocol in question, even including aspects that
are currently lacking.

However, I do not believe that a JWT profile for OAuth use is the place to
make changes to the core OAuth protocol that improve its privacy properties.
(If we can specify the token format in a way has better privacy properties
than alternative token formats, we should, of course, but we can't change
the protocol itself.)
Making changes to OAuth that improves its privacy properties is a laudable
goal, and I would happily read any I-Ds that proposed such protocol changes
(though I fear that the current deployment/semantics may constrain the
degree to which OAuth 2.0 can be improved and have much more hope for the
txauth group to produce a protocol with good privacy properties).  The
discussion so far has not convinced me that this document is the right
document in which to do so.

Thanks,

Ben



      

        

        

          
Hi Denis,

You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation.  In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.

Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works.  I think you do everyone a disservice for
attempting to suggest that this document should do so.

Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.

On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:


          

            
Hello Vittorio,

Your reply was amazingly fast. Responses are between the lines.



            

              
Thanks Denis for the thorough commentary.

/> The title of this spec./

Fixed, thanks!

/> The client MUST NOT inspect the content of the access token/


This is really a sticky point. I really want to acknowledge your PoV
on this, but at the same time I found this to be one of the biggest
sources of issues
in the use of JWT for access tokens hence I feel we really need to
give solid guidance here. Let me expand further on the reasoning
behind it,
and perhaps we can get to language that satisfies both PoVs.


To me the key point is that clients should not write /code/ that
inspects access tokens. Taking a dependency on the ability to do so is
ignoring fundamental information
about the architecture and relationships between OAuth roles, and
suggests an ability of the client to understand the semantic of the
content that cannot be assumed
in the general case. I expanded on the details in my former reply to
you on this topic, I would recommend referring to it.

Clients violating this simple principle has been one of the most
common sources of production issues I had to deal with in the past few
years, and one of the hardest
to remediate given that clients are hard to update and sometimes the
things they relied on were irremediably lost. This is why I am
inclined to put in here strong language.

That said: I have nothing against client developers examining a
network trace and drawing conclusions based on the content of what
they see. That doesn’t create any hard
dependencies and has no implications in respect to changes in the
solution behavior. However I am not sure how to phrase that in the
specification, given that referring
to the client inevitably refers to its code. I am open to suggestions.



            

            
First of all, a "*MUST NOT* "should not be placed in a privacy
considerations section, but in the main body of the document.
The goal of a privacy considerations section is to provide explanations,
but not to introduce additional requirements.


          

          
That's not actually a requirement.  In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.



          

            
Then after, since this section is about privacy considerations, it is
important to refer to an ISO standard that has been published 9 years ago.


          

          
Is it?  I don't see much precedent for IETF documents referencing this ISO
standard.  If it's so important you'd think that we'd have been citing it
with regularity.  Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.



          

            
It is ISO 29100 (Information technology — Security techniques — Privacy
framework). Most of the ISO standards need to be bought.
However, there are a few exceptions and this standard can be freely
downloaded from the ISO web site, if you accept some conditions,
using this URL:

     https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

ISO 29100, even if it is outdated on some aspects (it only deals with
two entities), identifies ten principles (See Table 3).

     1. Consent and choice

     2. Purpose legitimacy and specification

     3. Collection limitation

     4. Data minimization

     5. Use, retention and disclosure limitation

     6. Accuracy and quality

     7. Openness, transparency and notice

     8. Individual participation and access

     9. Accountability

     10. Information security

     11. Privacy compliance

If the client is unable to inspect the token, then openness and
transparency do not exist any more.

Since there is no formal protocol in OAuth 2.0  for "consent and
choice", the only way for a client for denying its consent is to inspect
the token
and to stop its transmission if the content of the token is not
considered to be adequate for it.

Since you are open to suggestions, would you please reconsider the text
I proposed: it simply states that if the client wants to inspect the token,
it will not necessarily be in a position to do it. It is simply a
warning, but this warning does not prevent the client to attempt to
inspect the token .

I will go one step further: if the client wants to inspect the token and
if the format of the token is unknown to the client, then the client
will simply
stop its further transmission. For some clients, preserving their
privacy may be more important than performing an access to a RS.


          

          
That may be true, but I agree with Vittorio that this document needs to
strongly discourage clients from doing so, since they would be breaking a
protocol invariant if they do.

Thanks,

Ben



          

            

              

                
  3)…


              

              
I have a pretty hard time following the chain of reasoning in this
section. Let me attempt to tackle it to the best of my understanding.

I think the key might be

/> a client should be able to choose whether it wishes the sub claim
to contain [..]

/

I don’t think that should be a choice left to the client. In business
systems, my experience is that the type of identifiers to be used
(when the IdP gives any choice at all)
  is established at resource provisioning time. I am not aware of
mechanisms thru which a client signals the nature of the identifier to
be used, nor that would be fully
feasible (the resource knows what it needs to perform its function).



            

            
Consent and choice is the first of the ten privacy principles. Since
OAuth has not been constructed taking into considerations this privacy
principle,
it is quite "normal" that you don't observe protocols able to do it at
the present time.



            

              
Furthermore:

/> which has nothing to do with uniqueness since the value changes for
every generated token.

/

Again, this is something that was touched on in my former reply to
your message. As long as an identifier identifies one resource only,
it satisfies uniqueness. It doesn’t have to be a singleton.



            

            
It is a matter of interpretation. I stick to the definition given in RFC
7519 (section 4.1.2):

*T**he subject value MUST either be scoped to be locally unique in the
context of the issuer or be globally unique.*

However, the "context of the issuer" is left undefined.



            

              
Finally, the scope is optional (for good reasons: 1^st party and non
delegation scenarios don’t require it) hence it cannot be relied upon
for properties that should hold in every scenario.



            

            
I would not say that the scope request parameter is a nice way to choose
which attributes should be placed in a JWT. However, considering the
limitations placed
in this document, it is the ONLY way to do. In my email sent before the
virtual meeting, I wrote: "Allowing a client to only specify a scope and
a resource is very restrictive".

Clause 2.2.2 (second paragraph) states:

***This profile does not introduce any mechanism for a client to**
******directly request the presence of specific claims in JWT access**
******tokens*, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Currently, the client has no control of the claims that will be placed
in a JWT and further more the current wording of privacy consideration
section
prevents the client to have any inspection of the attributes that have
been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not
fulfilled.

There are more implications. If, in the future, a mechanism is defined
to allow the client to choose the type of the attributes that should be
placed in a JWT,
then the "sub" claim is insufficient. Taking into consideration my
previous email, four types of attributes types would need to be specified:

The client should be able to choose whether it wishes a claim that contains:

   *      a global unique identifier for all ASs ("globally unique"),
   *      a unique identifier for each AS ("locally unique in the context
     of the issuer"),
   *      a different pseudonym for each RS, or
   *      a different pseudonym for each authorization token request.

Clause 2.2.2 states:

*   the authorization server can determine what additional**
******claims are required by a particular resource server* by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

I don't believe this is true in general. Considering its privacy
preferences, only the client may know what is appropriate: not the AS,
neither the RS.



            

              
In summary: per the preceding thread on this topic, the consensus was
that varying the sub content was a satisfactory way of protecting
against correlation.



            

            
"/if all you have is a hammer, everything looks like a nail/".

When the only parameter that can be used is the "sub" claim, then the
only solution is to place everything into it.



            

              
I don’t a gree that clients should have a mechanism to request
different sub flavors, as that decision should be done out of band by
the AS and RS; and the scope isn’t always available anyway.



            

            
While it would be nice to have such a mechanism, we are not going to
define such a mechanism during a second WGLC.

The privacy considerations section should only inform the readers about
the limitations of the protocol in terms of privacy.
I have proposed text to address the point. If you would prefer a
different wording to address this point, please make another proposal.



            

              
/> targeting of access tokens/

Let me think about that a bit longer.

I acknowledge that the decision of including an audience has the
effect of letting the AS track when the client accesses a particular
resource,
but at the same time that’s completely mainstream and very much by
design in a very large number of cases. As such, I find the language
you are suggesting to be potentially confusing, as it positions this
as an exception vs a privacy protecting mainstream that is in fact not
common,
and ascribes to the client more latitude than I believe is legitimate
to expect or grant.

I’ll try to come up with concise language that clarifies to the reader
that the current mechanism does allow AS tracking.



            

            
Please do so.

Denis



            

              
*From: *OAuth <oauth-bounces@ietf.org> on behalf of Denis
<denis.ietf@free.fr>
*Date: *Wednesday, April 29, 2020 at 09:12
*To: *"oauth@ietf.org" <oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens"

You will find four comments numbered 1) to 4).

*1) *The title of this spec. is:

JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens

So, this spec. is supposed to be targeted to OAuth *2.0. * However,
the header at the top of the page omits to mention it.

Currently, it is :

Internet-Draft OAuth Access Token JWT Profile           April 2020

It should rather be:

Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020

*2)* The following text is within section 6.

The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (for example by
switching from this profile to opaque tokens) hence any logic in the
client relying on the ability to read the access token content would
break without recourse.
Nonetheless, authorization servers should
not assume that clients will comply with the above.

It is of a primary importance that clients MAY be able to inspect
tokens before transmitting them.
The "MUST NOT" is not acceptable.

The above text should be replaced with:

Reading the access token content may be useful for the user to verify
that
the access token content matches with its expectations. However,
the authorization server and the resource server might decide to
change the
token format at any time.  Thus, the client should not expect to
always be
in a position to read the access token content.

The remaining of the text about this topic is fine.


*3) *The next topic is about the sub claim.

The text states:

Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the authorization
server might want to prevent correlation to preserve the desired
level of privacy. Authorization servers should choose how to assign
sub values according to the level of privacy required by each
situation.

I have a set of questions:

  1. How can authorization servers choose how to assign sub values
     according to the level of privacy required "by each situation" ?
  2. How can authorization servers know the level of privacy required
     "by each situation" ?
  3. How can the users be informed of the level of privacy required "by
     each situation" ?
  4. How can the users *consent* with the level of privacy required "by
     each situation" ?

Currently, the request MUST include either a resource parameter or an
aud claim parameter, while it MAY include a scope parameter.

The syntax of the scope parameter is a list of space-delimited,
case-sensitive strings (RFC 6749). It is thus subject to private
agreements
between clients and Authorization Servers. Since the scope is being
returned, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.

In theory, a client should be able to choose whether it wishes the sub
claim to contain :

   * a global unique identifier for all ASs ("globally unique"),
   * a unique identifier for each AS ("locally unique in the context of
     the issuer"),
   * a different pseudonym for each RS, or
   * a different pseudonym for each authorization token request.

The only variable parameter that it can use for this purpose in the
token request is the scope parameter.

RFC 7519 states is section 4.1.2:

The subject value MUST either be scoped to be locally unique in the
context of the issuer
or be globally unique.

It is quite hard to recognize that the sub claim is able to carry a
different pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for
case (d), which has nothing to do with uniqueness
since the value changes for every generated token.

This has implications about the following text:

For instance: if a solution requires preventing tracking
principal activities across multiple resource servers, the
authorization server should ensure that JWT access tokens meant for
different resource servers have distinct sub values that cannot be
correlated in the event of resource servers collusion.

Since it addresses case (c).

and also about the following text:

4.b) Similarly: if a solution requires preventing a resource server from
correlating the principal’s activity within the resource itself, the
authorization server should assign different sub values for every JWT
access token issued.

Since it addresses case (d).

This means that the current text placed in the privacy considerations
section was a good attempt to address the case,
but that the text needs to be revised.

Proposed text replacement for all the previously quoted sentences:

According to RFC 7519 (4.1.2): The subject value MUST either be scoped
to be locally unique in the context of the issuer or be globally unique.

When the sub claim contains a globally unique identifier, this allows
to correlate principal activities across multiple resource servers,
while in addition,
this globally unique identifier may also allow to correlate the
principal activities on servers where no access has been performed by
the principals
to these servers but where the same globally unique identifiers are
being used by these servers.

When the sub claim contains a locally unique identifier in the context
of the issuer, this also allows the tracking of principal activities
across multiple resource servers.

The scope request parameter is the only way to influence on the
content of the sub claim parameter. Its meaning is subject to a
private agreement
between the client and the AS, which means that the use of the scope
parameter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.

Since the scope parameter is being returned, it is a primary
importance that the returned scope matches with the expectations of
the client before transmitting
the token to a Resource Server.

However, there are other cases where the client would like to be able
to choose whether it wishes the sub claim to contain :
     - a different pseudonym for each RS so that different resource
servers will be unable to correlate its activities, or
     - a different pseudonym for each authorization token request, so
that the same resource server cannot correlate its activities
performed at different instant of time.

Considering the semantics of the sub claim, these two cases cannot be
currently supported.


*4) *The next topic is about the targeting of access tokens

Text had been proposed before the last conference call. Then, the
topic has been presented at the very end of the last conference call,
but no text has been included
in the next draft.

Here is a revised text be included in the privacy considerations section:

For security reasons, some clients may be willing to target their
access tokens but, for privacy reasons, may be unwilling to disclose
to Authorization Servers
an identification of the Resource Servers they are going to access, so
that Authorization Servers will be unable to know which resources
servers are being accessed.
The disclosure of the Resource Servers names allows the Authorization
Servers to list all the Resource Servers being access by all its users
and in addition to list pairs
of (Principal, Resource Servers) which allow to trace all the users
accesses to Resource Servers performed through a given Authorization
Server. When a token is targeted,
this profile does not contain provisions to address these two threats.

Denis

     Hi all,

     This is a second working group last call for "JSON Web Token (JWT)
     Profile for OAuth 2.0 Access Tokens".

     Here is the document:

     https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

     Please send your comments to the OAuth mailing list by April 29, 2020.

     Regards,

      Rifaat & Hannes



     _______________________________________________

     OAuth mailing list

     OAuth@ietf.org  <mailto:OAuth@ietf.org>

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



            

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


          

        

        



      

    

    


    

  


--------------37F8BA0FDAC9FA68AB0C0C21--


From nobody Mon May 11 06:30:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDF23A0ACD for ; Mon, 11 May 2020 06:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruMn32yCQoEt for ; Mon, 11 May 2020 06:30:14 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD9E3A0AC8 for ; Mon, 11 May 2020 06:30:14 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id z5so7103015ejb.3 for ; Mon, 11 May 2020 06:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kx0DFgBRR7YZp58mIOoMP06TGTWUw1A7YdDOq6SjBH4=; b=svZmaP8LNSw08S1LN8G52xWJ9DfL7Jgun2wjHtlWo9O6rR9/NF23Tv8bHkzTiDAt6y nKFWDhbO8d2g8C7Jd98tdg4gp01AqU/2CTo/+hHFoTmDTkmgQtDGfY6skWtjEU0llxv9 +qwij7kS1dlmpaNyvIdMOcZCc0uzTCneIcRp0qCZZNIRe+MrJRkNmoR9U0P/6ngnju7P pm1Kdj7Ne+STmFoTi0cp09af/UCwQoOJchGrI4D20ZshCXqQ0cCJv2R8Ccma/jvc5ktL cQsS/pCGsYQRCPfdCCMX7Actp7ic9cGNz/+8/X8yDwFT2EsIcU2OdGA1kW2baF01+bC3 4Siw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kx0DFgBRR7YZp58mIOoMP06TGTWUw1A7YdDOq6SjBH4=; b=Bal1JlIouCZMDjNNaiWTFM8zYMWFyQ0P3DwN/QRAgut7uAcR+sbKMSQA+SN/nldbmq 7R+syOMRneY57UusSXArMwAZ/Q/84rrwpY31YdOXab8tfiH5Xcr3R6+C+m/B4X+WDap9 Q2eoVonpUeQKZAqBLj1zRAriq8MGdjSpiYINwC4zJhLcQFKLJwneK05RSTBHuFCJyDJQ +HtG5/ZPxWHRPaUgXXBffyA+9/aXviTwj4hDAoHsnLon4rVjogE7/0xy5JgdA9GQPS/7 UEwwK9xvfH/j/qn50oddQw0Gno69kq4Yg28UfBRDIef/PUHh64sTClUArzS39xOswjj9 GHYw==
X-Gm-Message-State: AGi0Pua8Zx3hd85OnONPRKlI9PNgFgY+E4GuLh8rzuXIXNk6WLFfTjtS DK+cHuqxywNCIIZ4HiI5DcYkmZYlwQz2DvHiSz4=
X-Google-Smtp-Source: APiQypJYPtZ70D/DWEPVpOCnVZqGwocI7pIOrbaMxunE60cWZS1iizxIt7EkOKjVuezj2AyIQr/9rYtm3Pm7iT+044g=
X-Received: by 2002:a17:907:4272:: with SMTP id nq2mr13624642ejb.205.1589203812461;  Mon, 11 May 2020 06:30:12 -0700 (PDT)
MIME-Version: 1.0
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>
In-Reply-To: <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>
From: Jared Jennings 
Date: Mon, 11 May 2020 08:30:01 -0500
Message-ID: 
To: Denis 
Cc: Benjamin Kaduk , Vittorio Bertocci ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b7b20c05a55f58f7"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 13:30:17 -0000

--000000000000b7b20c05a55f58f7
Content-Type: text/plain; charset="UTF-8"

If I may, step in and offer a suggestion.

What if instead of "MUST NOT" replace with "SHOULD NOT"?

To me, (and this might be me), but MUST NOT describes a violation. As in I
broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a
guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the
token, the risk is therefore known and on the "implementer" of the
inspection.

Jared


On Mon, May 11, 2020 at 7:34 AM Denis  wrote:

> Hi Benjamin,
>
> We are making progress since we now understand better each other. You
> wrote several sentences on which I agree:
>
> "I do in fact agree that token inspection by a client can be useful in at
> least some situations".
>
> "I fully support having privacy considerations sections that discuss the
> privacy properties of the protocol in question,
>   *e**ven including aspects that are currently lacking*.
>
> "I do not believe that a JWT profile for OAuth use is the place to make
> changes to the core OAuth protocol that improve its privacy properties".
>
> I also accept your apologies.
>
> RFC 6749 is quite clear in section 1.4 that "The string [access token] *is
> usually opaqu**e* to the client".
> However, it does not mean that : "The client *MUST NOT* inspect the
> content of the access token".
> I believe the wording I proposed corresponds to the reality:
>
> There is no guarantee that token inspection can always be performed.
>
>

--000000000000b7b20c05a55f58f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


If I may, step in and offer a suggestion.=


What if instead of "=
MUST NOT" replace with "SHOULD NOT"?
<=
br>
To me, (and this might be me), but MUST NOT describes a viola=
tion. As in I broke the law. Conversely, I interpret, "SHOULD NOT"=
; as a recommendation, a guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect th=
e token, the risk is therefore known and on the "implementer" of =
the inspection.

Jared


On Mon, May 11, 2020 at 7:34 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Benjamin,

    


    

    
We are making progress since we now
      understand better each other. You wrote several sentences on which
      I agree:

    

      
"I do in fact agree that token
        inspection by a client can be useful in at least some
        situations".
      

      


      

      
"I fully support having privacy
        considerations sections that discuss the privacy properties of
        the protocol in question,

        =C2=A0 even including aspects that
          are currently lacking.

      


        "I do not believe that a JWT profile for OAuth use is the plac=
e
        to make changes to the core OAuth protocol that improve its
        privacy properties".

    

    
I also accept your apologies.

    


    

    
RFC 6749 is quite clear in section 1.4
      that "The string [access token] is usually opaque
      to the client". 

      However, it does not mean that : "The client MUST NOT
      inspect the content of the access token".

    
I believe the wording I proposed
      corresponds to the reality: 

    

    

      
There is no guarantee that token
        inspection can always be performed.




--000000000000b7b20c05a55f58f7--


From nobody Mon May 11 09:03:32 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FBA3A08E2 for ; Mon, 11 May 2020 09:03:02 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixxthKy4sbh1 for ; Mon, 11 May 2020 09:02:59 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB603A0B00 for ; Mon, 11 May 2020 09:02:41 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id w6so9070297ilg.1 for ; Mon, 11 May 2020 09:02:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=hO0PkDlaMihQE0+OwGVslWSrgNMx6mKcZW4wy7YoYJM=; b=zK8pWZp7uX786rnj1kD0IVwQpFuQPjbE6LJblZdcvEmTaHc2tcyKaV5kJI8L+u3d6G MUFjdzqF6A0jq07ec3j6PeLf5ZKrX4pNOdpFjVUwawRM6QhXCHuqBwzXQ5NeQwKxJUAE 8EaqcDWncuZY4cvtrRJF7xow+yLBMzw3OML/USRcoqzR15ja0cdDt2fFZEWbjxr/gq8O trACCtLRx6yfhhziLyNJbfltjRF/IisB2gzGGoP2Yv8/005118GnbmoFqM66h/90GrHI wyUIUuLEs/oZ/MWW57wNPwXS/FtxE/1hzkFv41C0Ae9hyQTgwtSwzlTxF9JQZ2UjfhCH lWgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hO0PkDlaMihQE0+OwGVslWSrgNMx6mKcZW4wy7YoYJM=; b=ZVsgtEHmJy+MBiGQNp8ZsJHLKDKnz9h0Kj1lRJudqfyRPoTgjq30kFpfT2NRKUUZrH zP0UhMgT0eadBBnwC12bPtvQOyyRz5P9QiEy/JO9o5J3Qm5eltOfKKkPwqGcPmqqLUxV MNGLzThClk78rgWDQW2+dDhYE9sxhsyc6Gb4x3j7/1XuGaAhtAKWRBBOfgn7J1NhQb0N SK6cfrGFYzrLnRZiA6XmXfUTjVCk3cz/o5Q0YtRa63sFFOS1MS9ZNctQDQfEVlspD88l 9UJctxQUny2bUrAia9ofu65oZ01yo63bKvCdjlH0kgJOV9yuAEyVToHqA/cwRrC22iQr K0Fg==
X-Gm-Message-State: AGi0PuYiAWWGgbW/kryp5jW/zHhrVybnVyRVYeDtY4pNziuajfN+RUI7 vMF48aNBygMJHo92lFiRmSCZQqSzrRo=
X-Google-Smtp-Source: APiQypIzYpWHj3XrBlLAqsPIuEd54qozyd3ti+cx8hob1x3nuGJVk91f/LrBbee1mle9zgUNhUD0lg==
X-Received: by 2002:a92:d98a:: with SMTP id r10mr6172364iln.127.1589212959932;  Mon, 11 May 2020 09:02:39 -0700 (PDT)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id m5sm5259310ilg.15.2020.05.11.09.02.38 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 09:02:38 -0700 (PDT)
Received: by mail-io1-f41.google.com with SMTP id w11so10313466iov.8 for ; Mon, 11 May 2020 09:02:38 -0700 (PDT)
X-Received: by 2002:a02:c998:: with SMTP id b24mr15938294jap.23.1589212957793;  Mon, 11 May 2020 09:02:37 -0700 (PDT)
MIME-Version: 1.0
From: Aaron Parecki 
Date: Mon, 11 May 2020 09:02:26 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000d27c2c05a561792b"
Archived-At: 
Subject: [OAUTH-WG] Redirect URIs in draft-ietf-oauth-security-topics
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 16:03:03 -0000

--000000000000d27c2c05a561792b
Content-Type: text/plain; charset="UTF-8"

The Security BCP has pretty clear language around requiring exact matching
of redirect URIs now.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1

However the Native Apps BCP has an exception for localhost URIs to allow
variable ports.

https://tools.ietf.org/html/rfc8252#section-7.3

Is the intention of the Security BCP to also prevent that use case?

If so, it should probably be spelled out explicitly, since there is
currently no mention of this. If not, then that exception should also be
repeated in the Security BCP, since it is currently somewhat ambiguous
whether the exception in the Native Apps BCP is still allowed.

Aaron Parecki

--000000000000d27c2c05a561792b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The Security BCP has pretty clear language around requirin=
g exact matching of redirect URIs now.=C2=A0


Is =
the intention of the Security BCP to also prevent that use case?

If so, it should probably be spelled out explicitly, since there i=
s currently no mention of this. If not, then that exception should also be =
repeated in the Security BCP, since it is currently somewhat ambiguous whet=
her the exception in the Native Apps BCP is still allowed.

Aaron Parecki



--000000000000d27c2c05a561792b--


From nobody Mon May 11 11:45:07 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303383A0C19 for ; Mon, 11 May 2020 11:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DCD6yGgwsFQ for ; Mon, 11 May 2020 11:45:04 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CC03A0EAF for ; Mon, 11 May 2020 11:44:12 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id b26so8412825lfa.5 for ; Mon, 11 May 2020 11:44:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BhWo5RtDaEwoBQZgzxd2EhoeiiZt8r0Mr2xfUq+5IL0=; b=AxKivzRN0mLDbtYoi9Dktyvcc6ZxjMT69O3zcaVyVerdYeUlztEpTw5Pm0uuvffhE/ nyz4XtfxuDAtHxnUGz3a0RkzDXjldi+TKcW3ahbAbyCR5DkUff/qPNl34B3bM6db4iNW CXS5sCnen5zZX6lnEkFUPwIeJtsCQIyoWP9Jesg9lv47lzPUxu6RMQSInbiuzZ0n+RCJ TDvxqqCGF8f/bLgE+hMJKo16wmUlsEONQ6hSX5UNqL/T9Uvb5K+rG60SgwRBBXKQmXRv y7zGtYVl25nafUSRp1dciUIc0fBBMmxL8hrh22aV+8Tg3xx/DjTtHVRde1vnpmMoR2Gf WcZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BhWo5RtDaEwoBQZgzxd2EhoeiiZt8r0Mr2xfUq+5IL0=; b=J54z2J9dBnaNR34+isIHL+ErjCaRzQx3oBcxlCy8ix6DpRvLlNE45ru0CS+FZpoH6+ NAvY129qgwi3bZO+Cv9Qq5HaBvaqmN5cOa5ZGDjm06q9uh8pcu5NUkRRdQhJWs+B88Xq i+oAlnMsO8midvjqefPe7cE/7ngzVeRwZF7tql3Jt4bv59hv69y/s5mOFKvdWrVfiBwy ey7QHY8SnBr8nO9Db2ZeMZpK1Z47iBs+Yl3MDJq6XgnvwZHWSnv/2uwYpvInSRdGgzfL p0GIGxxXUNhBPtADASea4zr81RVcnAMJlWrzh2fgxr6R4W0hsMk+OWb6qBhBjDGJWNyD KJcQ==
X-Gm-Message-State: AOAM531bC/Dw7iFVnLgY6TFEnDCQ+Kc7cAPInYQ4EpI3UHIJMnfUxzMV 8qeNZn/fxLX01lvpNnO2qX+ACVNxaxmeWtQ2MPhtihC0E1Zr9+FiscNlwmzdXzcpVBDzA/VBZ2j WTtjoUISPQ1/Rhg==
X-Google-Smtp-Source: ABdhPJxSrgSuQPAy0UQNV7LHnwc5k6f+eO27KsnruyDwj8ZreM6hxGln8IeDZCbbV7ud2yDouZbudj02yHS2koQWE84=
X-Received: by 2002:a19:f00b:: with SMTP id p11mr11926047lfc.210.1589222650905;  Mon, 11 May 2020 11:44:10 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 11 May 2020 12:43:44 -0600
Message-ID: 
To: Aaron Parecki 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000093db5105a563bbdd"
Archived-At: 
Subject: Re: [OAUTH-WG] Redirect URIs in draft-ietf-oauth-security-topics
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 18:45:06 -0000

--00000000000093db5105a563bbdd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I suspect it was an unintentional oversight in the Security BCP and that it
should be updated to allow for it.

On Mon, May 11, 2020 at 10:03 AM Aaron Parecki  wrote:

> The Security BCP has pretty clear language around requiring exact matchin=
g
> of redirect URIs now.
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2=
..1
> 
>
> However the Native Apps BCP has an exception for localhost URIs to allow
> variable ports.
>
> https://tools.ietf.org/html/rfc8252#section-7.3
>
> Is the intention of the Security BCP to also prevent that use case?
>
> If so, it should probably be spelled out explicitly, since there is
> currently no mention of this. If not, then that exception should also be
> repeated in the Security BCP, since it is currently somewhat ambiguous
> whether the exception in the Native Apps BCP is still allowed.
>
> Aaron Parecki
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

--00000000000093db5105a563bbdd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I suspect it was an unintentional oversight in the Securit=
y BCP and that it should be updated to allow for it. 

On Mon, May 11, 20=
20 at 10:03 AM Aaron Parecki <aaron=
@parecki.com> wrote:
The Security BCP has pretty clear language aro=
und requiring exact matching of redirect URIs now.=C2=A0

https://tools.ietf.org/html/draft-ietf-oaut=
h-security-topics-15#section-2..1

However =
the Native Apps BCP has an exception for localhost URIs to allow variable p=
orts.=C2=A0


Is the intention of the Secur=
ity BCP to also prevent that use case?

If so, it should =
probably be spelled out explicitly, since there is currently no mention of =
this. If not, then that exception should also be repeated in the Security B=
CP, since it is currently somewhat ambiguous whether the exception in the N=
ative Apps BCP is still allowed.

Aaron Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000093db5105a563bbdd--


From nobody Mon May 11 11:52:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7223A0C26 for ; Mon, 11 May 2020 11:52:17 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYCsJhF6-_9C for ; Mon, 11 May 2020 11:52:15 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219283A0C3F for ; Mon, 11 May 2020 11:52:14 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id s10so9628853iln.11 for ; Mon, 11 May 2020 11:52:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GAAyYzziUP+/oM6jpnebvsX5yR7hKN49ed5srWqFl6o=; b=AFtTZUWFlA9x8RnuN5MmvXZyM8Pis2QO7rHMpdCvQtP4Hd+Me2gS420901VhHHbK8r hYJTQ+9l+9+6qBYLzHe0OYjdQJ3kmeGZ786Q3DFnl0sT3ts2I2SRz2aaKEyrAZiIrCz5 dfRWkNyVgN0R6pYEV+lk8nRE/u8Gsatbmj5kFpMbRc9/WNUuQlHu0+8MswwXVf2PaQjo 93kYsthO8IRVmgCSjs/wJNXO4Vzc+964gmWdxy1aq+wfLIWAfFHRda8vGjLJyIKj9g8d e+kTbJKNPHRigbmMOl4fCx7VA7xeyAHIkClg4jjJnAdfZMp7zNveIzE6FSbvmlHRHn6A 926Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GAAyYzziUP+/oM6jpnebvsX5yR7hKN49ed5srWqFl6o=; b=bznmrblEu5bMNtCN5Kox28yldO6BIxH31SOLU+B/Gf9UfjD1bj8GAaYZx8WnPZxufR stUkMS6y7z7M0lVUgzPjii1DJpJ7Hy9skipNEA44n78+9dsCW+HsEz2GHLGkcH6zTbfk NvcLSU4zHepWgPS4c1PXjVQaMNuBbZq+fomn2P6UEXeR+WVvvfF2+nomHXKl2xiYChX5 JqJguG9/J5P5GjqPrMmv7zpk2c25QQMxJNnal+7e+KrcIkmpt3f1u9Zx8iFGfHyhtbe+ vMuLOeVXhvsjf6adtLeG+dLxaH7p/ZkVdFbdH8GGol9WjXynZtZaxK1kp6mnlbqRV00i i8yg==
X-Gm-Message-State: AGi0PuaL9rXXtOhUdFRJ4Zpvfbd7NBLBiztIhhoCIC/ADM9NEFWeM/LW t2phBrWc9w00htYQ6wtvYDdhI7qLmyo=
X-Google-Smtp-Source: APiQypJZ0mSadXRI7R9APhfEmdH+O80E3jRyiaEOhhaAMOajzLIJSwxdFEV5DnS7v0KMnpQ0yNHaxw==
X-Received: by 2002:a92:db46:: with SMTP id w6mr3636945ilq.237.1589223133493;  Mon, 11 May 2020 11:52:13 -0700 (PDT)
Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id q78sm3915218ilb.25.2020.05.11.11.52.12 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 11:52:12 -0700 (PDT)
Received: by mail-il1-f178.google.com with SMTP id s10so9628718iln.11 for ; Mon, 11 May 2020 11:52:12 -0700 (PDT)
X-Received: by 2002:a92:8c8a:: with SMTP id s10mr3422526ill.307.1589223131817;  Mon, 11 May 2020 11:52:11 -0700 (PDT)
MIME-Version: 1.0
From: Aaron Parecki 
Date: Mon, 11 May 2020 11:52:00 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000003db0fe05a563d8ec"
Archived-At: 
Subject: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 18:52:17 -0000

--0000000000003db0fe05a563d8ec
Content-Type: text/plain; charset="UTF-8"

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!

We would like to propose the following text, which is a slight variation
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1)
that begins with "If the client does not send the "code_challenge" in the
request..."

"An AS MUST reject requests without a code_challenge from public clients,
and MUST reject such requests from other clients unless there is reasonable
assurance that the client mitigates authorization code injection in other
ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0
and 2.1 clients simultaneously. The change from Neil's text is the
clarification of which threats, and changing to MUST instead of SHOULD. The
"MUST...unless" is more specific than "SHOULD", and since we are already
describing the explicit exception to the rule, it's more clear as a MUST
here.

Aaron Parecki

--0000000000003db0fe05a563d8ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the lively discussion around PKCE in OAuth 2.1 =
everyone!=C2=A0

We would like to propose the followi=
ng text, which is a slight variation from the text Neil proposed. This woul=
d replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/dr=
aft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins with "If th=
e client does not send the "code_challenge" in the request...&quo=
t;

"An AS MUST reject requests without a code=
_challenge from public clients, and MUST reject such requests from other cl=
ients unless there is reasonable assurance that the client mitigates author=
ization code injection in other ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonc=
e are described.

As Neil described, we believe thi=
s will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneously. =
The change from Neil's text is the clarification of which threats, and =
changing to MUST instead of SHOULD. The "MUST...unless" is more s=
pecific than "SHOULD", and since we are already describing the ex=
plicit exception to the rule, it's more clear as a MUST here.

Aaron Parecki



<=
/div>



--0000000000003db0fe05a563d8ec--


From nobody Mon May 11 11:55:18 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B93A0C41 for ; Mon, 11 May 2020 11:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeNKSOY7Hcvf for ; Mon, 11 May 2020 11:55:15 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5933A0C3F for ; Mon, 11 May 2020 11:55:14 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id n5so5648118wmd.0 for ; Mon, 11 May 2020 11:55:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P+qnc6pG1R0cL6njpScVO5FT6hMTQ8K2qOssfx0fMek=; b=edEJDdpf/LwcTcjTX8p37O8FYfJtsU6PXktW4fZ3/xvcpyHqoRFRJqbbeKSbFJohS3 mYB+UpsN1bj5wNdhAYlaygxe3/YvK9RYBHoUtSTx0uDuxyMP1pyZOQM/P/ejjm7FUYhB 5LrwQ0QM2I9wRkBhrLeLcfwbi/2yvdwCj72uk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P+qnc6pG1R0cL6njpScVO5FT6hMTQ8K2qOssfx0fMek=; b=cfOPH+mMsYPJ8l7F0QD7cp0C0uCzP1VEi1j/p/18G46hy61LPjtkA4GHN9WJZt1W42 AMme67pTd+UEk0HIBhF+nEAAfH1hJCzCNkkVdeFNhJQfjfUEqwffNzF1SKtBk6S8K6o6 PsxYpX7XTF4RHjwXJ1/HgUMbtSFMYMmvaKCHSAyvDIYDRtfnTTkZKwTSlh1YmoOby00i iE7PlPWYrlHIb7Z4fKneeF1CHSq9aMifw/HlC573T/tEAUME4fxz8akjyaL4nN0ARaU/ oGg46eqrrK7SezN5bgPvavxooVX4IhdOmQtC9y6y4NOOG5C0meO1bYjex4PEtvWH1N59 VIzA==
X-Gm-Message-State: AGi0PuYb/b4zmNKtznjVIlnGL/GB0O/b77WL/u7HlXSAaJ6GlX08e9IW a0B7ahY+unDbohET2UCEkYXNTWZNXpk=
X-Google-Smtp-Source: APiQypJwYxLsRLBXORXI+plgDxf1jnuOYsxwBHQERppMto/hna79Ye9fMXMtNJQ7gEYiV3wiyeNQLQ==
X-Received: by 2002:a7b:c955:: with SMTP id i21mr34996368wml.25.1589223312876;  Mon, 11 May 2020 11:55:12 -0700 (PDT)
Received: from [10.0.0.2] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id t4sm20124921wri.54.2020.05.11.11.55.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 11:55:12 -0700 (PDT)
From: Neil Madden 
Message-Id: <450592A8-C609-424D-B321-F9CD3DBAEFB0@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6924E5D8-55A8-424A-9621-8BA41CC19C74"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 11 May 2020 19:55:11 +0100
In-Reply-To: 
Cc: OAuth WG 
To: Aaron Parecki 
References: 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 18:55:17 -0000

--Apple-Mail=_6924E5D8-55A8-424A-9621-8BA41CC19C74
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I am happy with this proposed wording. Thanks for updating it.

=E2=80=94 Neil

> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>=20
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20
>=20
> We would like to propose the following text, which is a slight =
variation from the text Neil proposed. This would replace the paragraph =
in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1 =
)=
 that begins with "If the client does not send the "code_challenge" in =
the request..."
>=20
> "An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways. See section 9.7 for details."
>=20
> Section 9.7 is where the nuances of PKCE vs nonce are described.
>=20
> As Neil described, we believe this will allow ASs to support both =
OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is =
the clarification of which threats, and changing to MUST instead of =
SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we =
are already describing the explicit exception to the rule, it's more =
clear as a MUST here.
>=20
> Aaron Parecki
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_6924E5D8-55A8-424A-9621-8BA41CC19C74
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
am happy with this proposed wording. Thanks for updating it.

=E2=80=94 Neil



On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> =
wrote:

Thanks for the lively discussion around PKCE in =
OAuth 2.1 everyone! 

We would like to propose the following =
text, which is a slight variation from the text Neil proposed. This =
would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section=
-4.1.2.1) that begins with "If the client does not send the =
"code_challenge" in the request..."

"An AS MUST reject requests without a =
code_challenge from public clients, and MUST reject such requests from =
other clients unless there is reasonable assurance that the client =
mitigates authorization code injection in other ways. See section 9.7 =
for details."

Section 9.7 is where the nuances of =
PKCE vs nonce are described.

As Neil described, we believe this will =
allow ASs to support both OAuth 2.0 and 2.1 clients simultaneously. The =
change from Neil's text is the clarification of which threats, and =
changing to MUST instead of SHOULD. The "MUST...unless" is more specific =
than "SHOULD", and since we are already describing the explicit =
exception to the rule, it's more clear as a MUST here.

Aaron Parecki





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

=

--Apple-Mail=_6924E5D8-55A8-424A-9621-8BA41CC19C74--


From nobody Mon May 11 16:49:58 2020
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 9C00D3A0DC3; Mon, 11 May 2020 16:49:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.129.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <158924099259.12495.9856601834741788921@ietfa.amsl.com>
Date: Mon, 11 May 2020 16:49:52 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-23.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 23:49:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-23.txt
	Pages           : 32
	Date            : 2020-05-11

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-23


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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



From nobody Mon May 11 16:50:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6E3A0DB9 for ; Mon, 11 May 2020 16:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ubw6Y9tcL_0 for ; Mon, 11 May 2020 16:50:54 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D58C3A0DC9 for ; Mon, 11 May 2020 16:50:50 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id i15so13091771wrx.10 for ; Mon, 11 May 2020 16:50:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w0187EbWcChcpUoCiJGvjybrjQPJrUKyVHisD0iu59M=; b=fqojC5lQw3sJ0pTMelJ4/FJQqFTT702POQ2nQC7GR9bgap/G0nhS8bbfVsRTzO9Fpn YOcGmiUuD7ujRrYlxKEpDEjOwfGQHam42YqU2Pn9Ro5ESMHIjLlKpXCRUFsLVO9nScce nNMebsDQIOSlhr4E2ESyJawIs2reyiyG1kHrZxLfA0UoxXMVzvGmX9cqdgI2fI/cpD/l qCi6Uqc2RhOPSANnP4ew+0WVyWVHmH41N6ZWBeY2WKQmxoGASHZqIHsNHKjuYKVajG5m qqWI2xwimIfmpIk+CqZlTE2p27xN7qXP/07R9aXflMsly/j61SxTdVIoo2EzrEqBSs4n 9LvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w0187EbWcChcpUoCiJGvjybrjQPJrUKyVHisD0iu59M=; b=DQkGO5uwDbg8dE3nGfL7TAYL0CIp2tr6jpwIYUCSOEjuhHk/Vw6rZMQ1Qlhce03J4y iREqs6OA+RXgpRzSJB5f93zFAqazyA9ucdN/81XeJzDc3lf80bOT1P3ACrHWV0+UNs1q 3Y1h2sxmJhm0C+/clZRfFcWJ4+jWCosMVhvYVfsl1tmDh1lOppOzO+AEfeEF952YiAgN EhIqsG/LLNoQpzm/5xUKLv7qL6riKjQn2jua0QBy70we/PKAoQjB99xuK/bHptQWjMEv em3bOsSRn/maJKjw4qu67yJEJeq04TRpzj/NnRoJumWKr0dhYILk8jzS41Unf4K7yC8a 0Aeg==
X-Gm-Message-State: AGi0PuaS+Du9NTs5gCj9K+tHiB+XAWcfd6+w8gLOP2Us8HEtP2N5+QSG CSUbMmcSkxrNgWYAACuBktL0RCfj2p2Xt3ixU+5w8JVn
X-Google-Smtp-Source: APiQypIfrwStdWLpmzi0BruKS5HhlBbK/c84m99CMWXwcUzVtIIfk5XhQayGti3wT5KS/24knJyvi47phbe+Mtqx1RI=
X-Received: by 2002:adf:a1cb:: with SMTP id v11mr23300882wrv.39.1589241048501;  Mon, 11 May 2020 16:50:48 -0700 (PDT)
MIME-Version: 1.0
References: <158907186941.32364.3855329773244277548@ietfa.amsl.com> <0F682743-D799-4773-A1E7-09701CEB2BD1@lodderstedt.net>
In-Reply-To: <0F682743-D799-4773-A1E7-09701CEB2BD1@lodderstedt.net>
From: Nat Sakimura 
Date: Tue, 12 May 2020 08:50:36 +0900
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000002891ac05a568046b"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-22.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 23:50:58 -0000

--0000000000002891ac05a568046b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Torsten,

Thanks. I just updated the draft.

Best,

Nat Sakimura

On Sun, May 10, 2020 at 10:26 PM Torsten Lodderstedt  wrote:

> I just read over the diff between -21 and -22 and realised the example in
> Section 5.2.2.
>
> https://server.example.com/authorize?
>        response_type=3Dcode%20id_token
>        &client_id=3Ds6BhdRkqt3
>        &request_uri=3Dhttps%3A%2F%2Ftfp.example.org%2Frequest.jwt
>        %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
>
>  still has the =E2=80=9Cresponse_type" parameter. I think this parameter =
should be
> removed.
>
>
>
> > On 10. May 2020, at 02:51, internet-drafts@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol WG of the
> IETF.
> >
> >        Title           : The OAuth 2.0 Authorization Framework: JWT
> Secured Authorization Request (JAR)
> >        Authors         : Nat Sakimura
> >                          John Bradley
> >       Filename        : draft-ietf-oauth-jwsreq-22.txt
> >       Pages           : 32
> >       Date            : 2020-05-07
> >
> > Abstract:
> >   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
> >   query parameter serialization, which means that Authorization Request
> >   parameters are encoded in the URI of the request and sent through
> >   user agents such as web browsers.  While it is easy to implement, it
> >   means that (a) the communication through the user agents are not
> >   integrity protected and thus the parameters can be tainted, and (b)
> >   the source of the communication is not authenticated.  Because of
> >   these weaknesses, several attacks to the protocol have now been put
> >   forward.
> >
> >   This document introduces the ability to send request parameters in a
> >   JSON Web Token (JWT) instead, which allows the request to be signed
> >   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
> >   (JWE) so that the integrity, source authentication and
> >   confidentiality property of the Authorization Request is attained.
> >   The request can be sent by value or by reference.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-22
> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-22
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-22
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--0000000000002891ac05a568046b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Torsten,=C2=A0

Thanks. I just updated t=
he draft.=C2=A0

Best,=C2=A0

Nat Sakimura

On Sun, May 10, 2020 at 10:26 PM Torsten Lodderstedt &=
lt;torsten=3D40lodderst=
edt.net@dmarc.ietf.org> wrote:
I just read over the diff between -21 and -22 and rea=
lised the example in Section 5.2.2.



https://server.example.com/authorize?

=C2=A0 =C2=A0 =C2=A0 =C2=A0response_type=3Dcode%20id_token

=C2=A0 =C2=A0 =C2=A0 =C2=A0&client_id=3Ds6BhdRkqt3

=C2=A0 =C2=A0 =C2=A0 =C2=A0&request_uri=3Dhttps%3A%2F%2Ftfp.example.org<=
/a>%2Frequest.jwt

=C2=A0 =C2=A0 =C2=A0 =C2=A0%2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM


=C2=A0still has the =E2=80=9Cresponse_type" parameter. I think this pa=
rameter should be removed. 







> On 10. May 2020, at 02:51, internet-drafts@ietf.org wrote:

> 

> 

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol WG of the =
IETF.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Reque=
st (JAR)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =
Nat Sakimura

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 John Bradley

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
ietf-oauth-jwsreq-22.txt

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 32

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2020-05-07

> 

> Abstract:

>=C2=A0 =C2=A0The authorization request in OAuth 2.0 described in RFC 67=
49 utilizes

>=C2=A0 =C2=A0query parameter serialization, which means that Authorizat=
ion Request

>=C2=A0 =C2=A0parameters are encoded in the URI of the request and sent =
through

>=C2=A0 =C2=A0user agents such as web browsers.=C2=A0 While it is easy t=
o implement, it

>=C2=A0 =C2=A0means that (a) the communication through the user agents a=
re not

>=C2=A0 =C2=A0integrity protected and thus the parameters can be tainted=
, and (b)

>=C2=A0 =C2=A0the source of the communication is not authenticated.=C2=
=A0 Because of

>=C2=A0 =C2=A0these weaknesses, several attacks to the protocol have now=
 been put

>=C2=A0 =C2=A0forward.

> 

>=C2=A0 =C2=A0This document introduces the ability to send request param=
eters in a

>=C2=A0 =C2=A0JSON Web Token (JWT) instead, which allows the request to =
be signed

>=C2=A0 =C2=A0with JSON Web Signature (JWS) and encrypted with JSON Web =
Encryption

>=C2=A0 =C2=A0(JWE) so that the integrity, source authentication and

>=C2=A0 =C2=A0confidentiality property of the Authorization Request is a=
ttained.

>=C2=A0 =C2=A0The request can be sent by value or by reference.

> 

> 

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft=
-ietf-oauth-jwsreq/

> 

> There are also htmlized versions available at:

> https://tools.ietf.org/html/draft-ietf-oa=
uth-jwsreq-22

> https://datatracker.ietf.org/do=
c/html/draft-ietf-oauth-jwsreq-22

> 

> A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=
=3Ddraft-ietf-oauth-jwsreq-22

> 

> 

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at tools.ietf.org.
> 

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

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

> 

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Found=
ation
http://nat.=
sakimura.org/
@_nat_en


--0000000000002891ac05a568046b--


From nobody Mon May 11 16:55:34 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3084C3A0DBD for ; Mon, 11 May 2020 16:55:33 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2VplESQic2K for ; Mon, 11 May 2020 16:55:31 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B6C3A0DAC for ; Mon, 11 May 2020 16:55:30 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id j8so11893167iog.13 for ; Mon, 11 May 2020 16:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UUArDRNV9aOiFwwf7Y/KEBQcUpga9QNHY09JfObMtqg=; b=cscjbaGwav4hW5fsVLCnutlN3KU6NhaZqKHBeKcrHhL9XwJcUVku/8io7A1zHR4o/0 EVXMM7Yuz90Urbo25Z3UhvY2FPYa2iKIlMkQvUfF9fvWvaBgCJWeRVWFAxu1MlB78lUJ Q91sRVgF004IJIOlEkXprqxxpz2f8R4zdTexW87wd0ZRgIFFEbCUgJfbx3IwQf8NT8BP J4l2ipa6J7gs3p21SGj6NTmQ4GOF2ectyrWGuSnL8XdfWFRfW5UzTu4XD6D50yPFgl7L 0eHGAzQOPwWIzsCoot+wcjcMCg03b3dnKMj63g7ziLU187krpFEtuuZyaQhoPTCYlmCk pQRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UUArDRNV9aOiFwwf7Y/KEBQcUpga9QNHY09JfObMtqg=; b=Ra2cCFQSPy8MXlMQRH28+g6X4vspcz29Gi5Mp+eigqet+NyRP1TJfBu6a1X931syrb PhpDPK+y21yoAODv3hQya687XtT/+nmg6QtQp7lTnWEqwH9yULa6IxU9eo85xcpI9GA1 BLp0O9SUIH+opMa78f8kU9uusglVOwAXdkgZwcUah1TcpSRC4kdyWw2UBAoG3uhabld2 2ND36U5kXEEpoVdIz+oO2iuQYrcaJvmWnsqMG04rUnXm4MafHTH8igkjPJIMbmDwZqFo puZNnDR9O4f12J98eJ2eUCxRgI5GV5DrDHrG2Ew/3k+YeJcT7oBmkTWb10+VamQJtASY sm5g==
X-Gm-Message-State: AGi0PuZSfafPrZrXZbJIA/NFptAbMdROQ1SXfuD8qMcmVbRTRRjAOezC 9/PuiPaZtakR1Ijb5DrJUrSkP51Ven0=
X-Google-Smtp-Source: APiQypJpv8DRYmdiHMHFaxnNKPevf8K1hADXCvxQokn9B2cpOhcbqOx8TdLkFiNBbyl0nBcc6ijrsg==
X-Received: by 2002:a05:6602:164c:: with SMTP id y12mr17085631iow.138.1589241329521;  Mon, 11 May 2020 16:55:29 -0700 (PDT)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com. [209.85.166.44]) by smtp.gmail.com with ESMTPSA id e13sm2643409ils.27.2020.05.11.16.55.28 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 16:55:28 -0700 (PDT)
Received: by mail-io1-f44.google.com with SMTP id d7so11937887ioq.5 for ; Mon, 11 May 2020 16:55:28 -0700 (PDT)
X-Received: by 2002:a6b:ea11:: with SMTP id m17mr11754763ioc.149.1589241328136;  Mon, 11 May 2020 16:55:28 -0700 (PDT)
MIME-Version: 1.0
References:  <450592A8-C609-424D-B321-F9CD3DBAEFB0@forgerock.com>
In-Reply-To: <450592A8-C609-424D-B321-F9CD3DBAEFB0@forgerock.com>
From: Aaron Parecki 
Date: Mon, 11 May 2020 16:55:17 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000d3838905a56814f9"
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 May 2020 23:55:33 -0000

--000000000000d3838905a56814f9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also
update section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into the
authorization response by attackers. The use of the `code_challenge`
parameter is RECOMMENDED to this end. For confidential clients, the
OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used
instead of or in addition to the `code_challenge` parameter for this
purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
transaction-specific and securely bound to the client and the user agent
in which the transaction was started.

This change better clarifies the specific circumstances under which the
"nonce" parameter is sufficient to protect against authorization code
injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden 
wrote:

> I am happy with this proposed wording. Thanks for updating it.
>
> =E2=80=94 Neil
>
> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
>
> We would like to propose the following text, which is a slight variation
> from the text Neil proposed. This would replace the paragraph in 4.1.2.1 =
(
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1)
> that begins with "If the client does not send the "code_challenge" in the
> request..."
>
> "An AS MUST reject requests without a code_challenge from public clients,
> and MUST reject such requests from other clients unless there is reasonab=
le
> assurance that the client mitigates authorization code injection in other
> ways. See section 9.7 for details."
>
> Section 9.7 is where the nuances of PKCE vs nonce are described.
>
> As Neil described, we believe this will allow ASs to support both OAuth
> 2.0 and 2.1 clients simultaneously. The change from Neil's text is the
> clarification of which threats, and changing to MUST instead of SHOULD. T=
he
> "MUST...unless" is more specific than "SHOULD", and since we are already
> describing the explicit exception to the rule, it's more clear as a MUST
> here.
>
> Aaron Parecki
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--000000000000d3838905a56814f9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you Neil.

To address Mike&#=
39;s concerns in the previous threads, I would like to also update section =
9.7 with the following text:

Cl=
ients MUST prevent injection (replay) of authorization codes into the 
a=
uthorization response by attackers. The use of the `code_challenge`
para=
meter is RECOMMENDED to this end. For confidential clients, the 
OpenID =
Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used 
ins=
tead of or in addition to the `code_challenge` parameter for this 
purpo=
se. The `code_challenge` or OpenID Connect `nonce` value MUST be
transac=
tion-specific and securely bound to the client and the user agent 
in wh=
ich the transaction was started.

This c=
hange better clarifies the specific circumstances under which the "non=
ce" parameter is sufficient to protect against authorization code inje=
ction.

Aaron Parecki

On Mon, May 11, 2020 at =
11:55 AM Neil Madden <neil.=
madden@forgerock.com> wrote:
I am happy wi=
th this proposed wording. Thanks for updating it.

=E2=80=
=94 Neil



On 11 May 2020, at 19:52, Aaron Par=
ecki <aaron@parec=
ki.com> wrote:

Thanks for the lively =
discussion around PKCE in OAuth 2.1 everyone!=C2=A0

=
We would like to propose the following text, which is a slight variation fr=
om the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-=
1-02#section-4.1.2.1) that begins with "If the client does not sen=
d the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from publi=
c clients, and MUST reject such requests from other clients unless there is=
 reasonable assurance that the client mitigates authorization code injectio=
n in other ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to s=
upport both OAuth 2.0 and 2.1 clients simultaneously. The change from Neil&=
#39;s text is the clarification of which threats, and changing to MUST inst=
ead of SHOULD. The "MUST...unless" is more specific than "SH=
OULD", and since we are already describing the explicit exception to t=
he rule, it's more clear as a MUST here.

Aaron=
 Parecki




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


--000000000000d3838905a56814f9--


From nobody Mon May 11 17:21:46 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41843A0DD8 for ; Mon, 11 May 2020 17:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level: 
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPKbt2KxGNMn for ; Mon, 11 May 2020 17:21:42 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640138.outbound.protection.outlook.com [40.107.64.138]) (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 800E53A0DD6 for ; Mon, 11 May 2020 17:21:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kcFo83EHyhRFYUPckPsF2JiTv9tMiZz0SyFwlEmPbUTRRyJ9nhCQocNQAoRheAoQ3q3946HOO6zT/CCU23vMOeH9ogLW2DWK3olthrzoZoyU1QW3keoQZAgvN7OmzYFGdCQob0i39wxOlV82bLYYSmY14XFgpmxjX/ohFpsnVUJZwBzux5aTr1Yrik17YjCtcHl3qfUio+lGz+0Ns/SGeI8HqereD1c9PXxVumD/3YKnW2ZtwGCre48d38BoaQqgGwlIGDZ2KDQ4F+9hNOTOGjObvKZXonH6jrsa4o6J9Z6tfL5ey9shfkHPi/0TepAgSY2URHukiVSFzzGpsDF0zQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=amN789qLLX2QosVuJvvNYIRDR3IdbOmmZf3D+mwY0Ak=; b=c35d6H4nk6df8mhXKq8+cChb5wW0NdFbionOnsKP0yF/6KDM16TwTKUcwa/nkRgV09MOTb01IlyREsei7RCfQOA9BxP2md1py57kGWUbBfdk7jhf0t7mGUfjbQ9T9Se3LWiwS56gs3PaHD5r9i2g+3SuTPs4aqfUMxWDw8m2nq6x/4uaNbUxsqdtPoA9BebnyJQdsCK5ZfAAi3pZaosncYVNEXkfVZVnrlzXNyQ2bW7/IL/CbYJU1houZJ/KxWpzFyW3CcxoQ8Vqh76oSjTZvDZIb02dML0kNcLKnaQoIPEZ93kimi3Qweq7hmZne9cH7rirUXNmyns9GWEx77jyzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=amN789qLLX2QosVuJvvNYIRDR3IdbOmmZf3D+mwY0Ak=; b=Nv3VXQ/TKGaEgEZvBbZ2BfFUTJuQkUI1SVlOdlykBRRPg8XNVYZs3mVlxT/91VzOv0RCjcHkznXuG/1+mZSeydr9BwKGztmkqTzGXuXWTUD29egjEjLmvCpqDGYWGUS7HhiN8eEpByYHobti6rcGN7YKb1fx9TZkLhx6weN4D3s=
Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0704.namprd00.prod.outlook.com (2603:10b6:208:1d0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3032.0; Tue, 12 May 2020 00:21:40 +0000
Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283%7]) with mapi id 15.20.3035.000; Tue, 12 May 2020 00:21:40 +0000
From: Mike Jones 
To: Aaron Parecki , OAuth WG 
Thread-Topic: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
Thread-Index: AdYn801szb1PE0FGSyKMnB6cjcxG1g==
Date: Tue, 12 May 2020 00:21:40 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=13634fd6-f522-4704-a3fc-00006e0411d9; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-12T00:18:33Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 70182f22-aada-4f51-8dd5-08d7f60a7153
x-ms-traffictypediagnostic: MN2PR00MB0704:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0401647B7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VdviVHuS05lWP51Peqcnt5vlDckqPmpvQQ33XbCopnM9TEKEwBLciGF2DdhH7Z4Z0kov6d/x8MG1dPLyj+hdN7RScVIP+6qeHbAY/wsdsOr1g5Zv9jMCPndj9gt2CdlHUmEzBJsKa4ghFcTzxSgIIvSsfkCKuL7+SOVX0Vam0Z0flOh97aRWZi4EVttUh0LBQGMeEsu3hdCyTQw92UMw4Vb+IOXSHFv4CAvpqmhM0mGE1e6178fe5gF3N2V3/sEh/92jZ7qY+LfJkrpP8Ea93PI9kqMuc1nk2knCSJCDpainbc6VoyrZeuTuBGCzlR1/6OYyzT8HM5Po4FQySmr35lP7FV9SZhwWjK0kGn0k5Et/FSO5vNUvp/hcEadk7m7qnvfOJspKuxLyYaIiI7KURPqCib9WE+ErchrzReicDCYQSAkUfgIqmGERwN9efYkV50u3jy+hotc/kltub8wEXV9qxgP3k7lPGr/zf/Ssh08=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(396003)(366004)(39860400002)(376002)(136003)(33430700001)(4326008)(966005)(82950400001)(26005)(6506007)(71200400001)(55016002)(53546011)(478600001)(8676002)(82960400001)(33440700001)(166002)(9686003)(76116006)(86362001)(33656002)(66476007)(66446008)(64756008)(66946007)(2906002)(66556008)(8990500004)(186003)(10290500003)(8936002)(5660300002)(110136005)(7696005)(52536014)(316002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: cizAJNKbKGYBGfqri930pjFWw474jmqM9VtOt7IUZdIwxZtwH7T5av1uLG4U+bx8e00DGdoB45QwDbqXAMLgotrAfBQUozRjbBwycUkRSow5NGAQfpanRb2CrbYOsQ5Q/yzR1zCbPhVoRHAzW1+1Ib4S7wFKMeBwlV/OLwd6o8MwaVcfVUz3LGQu6NDawBhqBhuEGYtpEUvTyxcNgws7zNab6uBGJdwvTQg9roeKJJEyr3rYgiEE3UB6N67/aEQ4hVeBl2DgH6srsARNcTwQuxvTBXS0PD1QHP8nLaH7jybnZXKXEN/xAuhsxLhPygvRDqoGiNTANxvtiTs/k8nJAUothTjULrgh+2RpWmC2znAOFl28yNMBjlLG/c0/LKM4tG+yW6IdIumZX5/GF3Vasps5uQ4hUkVlPulwmriZDmKFMp1Qc0M7F4CfWUKd9HO3Xu+/gZ8sXPHruqQ6YRzaKL4dduXVE859qN1q4uRH6yM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB068633B7B72E5416AA8984D1F5BE0MN2PR00MB0686namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 70182f22-aada-4f51-8dd5-08d7f60a7153
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 00:21:40.5471 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Smq3d/0upD0HK33u69A+r/Z+QsBPJhvUFKHzFD2dWDz79MOrKtbJSHvC2aGxZPYvQXKdg4KMc9ovSei3T6QsHA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0704
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 00:21:45 -0000

--_000_MN2PR00MB068633B7B72E5416AA8984D1F5BE0MN2PR00MB0686namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhdCB3b3JrcyBmb3IgbWUuICBUaGFua3MgYWxsIGZvciB0aGUgdXNlZnVsIGJhY2stYW5kLWZv
cnRoIHRoYXQgZ290IHVzIHRvIHRoaXMgcG9pbnQgb2YgY2xhcml0eS4gIEkgc3VzcGVjdCBtYW55
IG9mIHVzIGxlYXJuZWQgdGhpbmdzIGFsb25nIHRoZSB3YXk7IEkga25vdyB0aGF0IEkgZGlkIQ0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Q2hlZXJzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb20+
DQpTZW50OiBNb25kYXksIE1heSAxMSwgMjAyMCA0OjU1IFBNDQpUbzogT0F1dGggV0cgPG9hdXRo
QGlldGYub3JnPg0KQ2M6IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPjsg
TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmU6IFtP
QVVUSC1XR10gcHJvcG9zZWQgcmVzb2x1dGlvbiBmb3IgUEtDRSBpbiBPQXV0aCAyLjENCg0KVGhh
bmsgeW91IE5laWwuDQoNClRvIGFkZHJlc3MgTWlrZSdzIGNvbmNlcm5zIGluIHRoZSBwcmV2aW91
cyB0aHJlYWRzLCBJIHdvdWxkIGxpa2UgdG8gYWxzbyB1cGRhdGUgc2VjdGlvbiA5Ljcgd2l0aCB0
aGUgZm9sbG93aW5nIHRleHQ6DQoNCkNsaWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlvbiAocmVw
bGF5KSBvZiBhdXRob3JpemF0aW9uIGNvZGVzIGludG8gdGhlDQphdXRob3JpemF0aW9uIHJlc3Bv
bnNlIGJ5IGF0dGFja2Vycy4gVGhlIHVzZSBvZiB0aGUgYGNvZGVfY2hhbGxlbmdlYA0KcGFyYW1l
dGVyIGlzIFJFQ09NTUVOREVEIHRvIHRoaXMgZW5kLiBGb3IgY29uZmlkZW50aWFsIGNsaWVudHMs
IHRoZQ0KT3BlbklEIENvbm5lY3QgYG5vbmNlYCBwYXJhbWV0ZXIgYW5kIElEIFRva2VuIENsYWlt
IHt7T3BlbklEfX0gTUFZIGJlIHVzZWQNCmluc3RlYWQgb2Ygb3IgaW4gYWRkaXRpb24gdG8gdGhl
IGBjb2RlX2NoYWxsZW5nZWAgcGFyYW1ldGVyIGZvciB0aGlzDQpwdXJwb3NlLiBUaGUgYGNvZGVf
Y2hhbGxlbmdlYCBvciBPcGVuSUQgQ29ubmVjdCBgbm9uY2VgIHZhbHVlIE1VU1QgYmUNCnRyYW5z
YWN0aW9uLXNwZWNpZmljIGFuZCBzZWN1cmVseSBib3VuZCB0byB0aGUgY2xpZW50IGFuZCB0aGUg
dXNlciBhZ2VudA0KaW4gd2hpY2ggdGhlIHRyYW5zYWN0aW9uIHdhcyBzdGFydGVkLg0KDQpUaGlz
IGNoYW5nZSBiZXR0ZXIgY2xhcmlmaWVzIHRoZSBzcGVjaWZpYyBjaXJjdW1zdGFuY2VzIHVuZGVy
IHdoaWNoIHRoZSAibm9uY2UiIHBhcmFtZXRlciBpcyBzdWZmaWNpZW50IHRvIHByb3RlY3QgYWdh
aW5zdCBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uLg0KDQpBYXJvbiBQYXJlY2tpDQoNCk9u
IE1vbiwgTWF5IDExLCAyMDIwIGF0IDExOjU1IEFNIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBm
b3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4gd3JvdGU6DQpJ
IGFtIGhhcHB5IHdpdGggdGhpcyBwcm9wb3NlZCB3b3JkaW5nLiBUaGFua3MgZm9yIHVwZGF0aW5n
IGl0Lg0KDQrigJQgTmVpbA0KDQoNCk9uIDExIE1heSAyMDIwLCBhdCAxOTo1MiwgQWFyb24gUGFy
ZWNraSA8YWFyb25AcGFyZWNraS5jb208bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPj4gd3JvdGU6
DQoNClRoYW5rcyBmb3IgdGhlIGxpdmVseSBkaXNjdXNzaW9uIGFyb3VuZCBQS0NFIGluIE9BdXRo
IDIuMSBldmVyeW9uZSENCg0KV2Ugd291bGQgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcg
dGV4dCwgd2hpY2ggaXMgYSBzbGlnaHQgdmFyaWF0aW9uIGZyb20gdGhlIHRleHQgTmVpbCBwcm9w
b3NlZC4gVGhpcyB3b3VsZCByZXBsYWNlIHRoZSBwYXJhZ3JhcGggaW4gNC4xLjIuMSAoaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhcmVja2ktb2F1dGgtdjItMS0wMiNzZWN0aW9u
LTQuMS4yLjEpIHRoYXQgYmVnaW5zIHdpdGggIklmIHRoZSBjbGllbnQgZG9lcyBub3Qgc2VuZCB0
aGUgImNvZGVfY2hhbGxlbmdlIiBpbiB0aGUgcmVxdWVzdC4uLiINCg0KIkFuIEFTIE1VU1QgcmVq
ZWN0IHJlcXVlc3RzIHdpdGhvdXQgYSBjb2RlX2NoYWxsZW5nZSBmcm9tIHB1YmxpYyBjbGllbnRz
LCBhbmQgTVVTVCByZWplY3Qgc3VjaCByZXF1ZXN0cyBmcm9tIG90aGVyIGNsaWVudHMgdW5sZXNz
IHRoZXJlIGlzIHJlYXNvbmFibGUgYXNzdXJhbmNlIHRoYXQgdGhlIGNsaWVudCBtaXRpZ2F0ZXMg
YXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBpbiBvdGhlciB3YXlzLiBTZWUgc2VjdGlvbiA5
LjcgZm9yIGRldGFpbHMuIg0KDQpTZWN0aW9uIDkuNyBpcyB3aGVyZSB0aGUgbnVhbmNlcyBvZiBQ
S0NFIHZzIG5vbmNlIGFyZSBkZXNjcmliZWQuDQoNCkFzIE5laWwgZGVzY3JpYmVkLCB3ZSBiZWxp
ZXZlIHRoaXMgd2lsbCBhbGxvdyBBU3MgdG8gc3VwcG9ydCBib3RoIE9BdXRoIDIuMCBhbmQgMi4x
IGNsaWVudHMgc2ltdWx0YW5lb3VzbHkuIFRoZSBjaGFuZ2UgZnJvbSBOZWlsJ3MgdGV4dCBpcyB0
aGUgY2xhcmlmaWNhdGlvbiBvZiB3aGljaCB0aHJlYXRzLCBhbmQgY2hhbmdpbmcgdG8gTVVTVCBp
bnN0ZWFkIG9mIFNIT1VMRC4gVGhlICJNVVNULi4udW5sZXNzIiBpcyBtb3JlIHNwZWNpZmljIHRo
YW4gIlNIT1VMRCIsIGFuZCBzaW5jZSB3ZSBhcmUgYWxyZWFkeSBkZXNjcmliaW5nIHRoZSBleHBs
aWNpdCBleGNlcHRpb24gdG8gdGhlIHJ1bGUsIGl0J3MgbW9yZSBjbGVhciBhcyBhIE1VU1QgaGVy
ZS4NCg0KQWFyb24gUGFyZWNraQ0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQoNCg==

--_000_MN2PR00MB068633B7B72E5416AA8984D1F5BE0MN2PR00MB0686namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz
cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx
LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhdCB3b3JrcyBmb3IgbWUuJm5ic3A7IFRoYW5rcyBhbGwg
Zm9yIHRoZSB1c2VmdWwgYmFjay1hbmQtZm9ydGggdGhhdCBnb3QgdXMgdG8gdGhpcyBwb2ludCBv
ZiBjbGFyaXR5LiZuYnNwOyBJIHN1c3BlY3QgbWFueSBvZiB1cyBsZWFybmVkIHRoaW5ncyBhbG9u
ZyB0aGUgd2F5OyBJIGtub3cgdGhhdCBJIGRpZCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGVlcnMs
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt
LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBB
YXJvbiBQYXJlY2tpICZsdDthYXJvbkBwYXJlY2tpLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+
IE1vbmRheSwgTWF5IDExLCAyMDIwIDQ6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+IE9BdXRoIFdHICZs
dDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IE5laWwgTWFkZGVuICZsdDtuZWls
Lm1hZGRlbkBmb3JnZXJvY2suY29tJmd0OzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0Bt
aWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBwcm9w
b3NlZCByZXNvbHV0aW9uIGZvciBQS0NFIGluIE9BdXRoIDIuMTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IE5laWwuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gYWRkcmVzcyBNaWtlJ3MgY29uY2Vy
bnMgaW4gdGhlIHByZXZpb3VzIHRocmVhZHMsIEkgd291bGQgbGlrZSB0byBhbHNvIHVwZGF0ZSBz
ZWN0aW9uIDkuNyB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Q2xpZW50cyBNVVNUIHByZXZlbnQgaW5qZWN0aW9uIChyZXBsYXkp
IG9mIGF1dGhvcml6YXRpb24gY29kZXMgaW50byB0aGUNCjxicj4NCmF1dGhvcml6YXRpb24gcmVz
cG9uc2UgYnkgYXR0YWNrZXJzLiBUaGUgdXNlIG9mIHRoZSBgY29kZV9jaGFsbGVuZ2VgPGJyPg0K
cGFyYW1ldGVyIGlzIFJFQ09NTUVOREVEIHRvIHRoaXMgZW5kLiBGb3IgY29uZmlkZW50aWFsIGNs
aWVudHMsIHRoZSA8YnI+DQpPcGVuSUQgQ29ubmVjdCBgbm9uY2VgIHBhcmFtZXRlciBhbmQgSUQg
VG9rZW4gQ2xhaW0ge3tPcGVuSUR9fSBNQVkgYmUgdXNlZCA8YnI+DQppbnN0ZWFkIG9mIG9yIGlu
IGFkZGl0aW9uIHRvIHRoZSBgY29kZV9jaGFsbGVuZ2VgIHBhcmFtZXRlciBmb3IgdGhpcyA8YnI+
DQpwdXJwb3NlLiBUaGUgYGNvZGVfY2hhbGxlbmdlYCBvciBPcGVuSUQgQ29ubmVjdCBgbm9uY2Vg
IHZhbHVlIE1VU1QgYmU8YnI+DQp0cmFuc2FjdGlvbi1zcGVjaWZpYyBhbmQgc2VjdXJlbHkgYm91
bmQgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVzZXIgYWdlbnQgPGJyPg0KaW4gd2hpY2ggdGhlIHRy
YW5zYWN0aW9uIHdhcyBzdGFydGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBjaGFuZ2UgYmV0dGVyIGNsYXJpZmllcyB0
aGUgc3BlY2lmaWMgY2lyY3Vtc3RhbmNlcyB1bmRlciB3aGljaCB0aGUgJnF1b3Q7bm9uY2UmcXVv
dDsgcGFyYW1ldGVyIGlzIHN1ZmZpY2llbnQgdG8gcHJvdGVjdCBhZ2FpbnN0IGF1dGhvcml6YXRp
b24gY29kZSBpbmplY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFhcm9uIFBhcmVja2k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXkgMTEsIDIwMjAgYXQgMTE6NTUg
QU0gTmVpbCBNYWRkZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2su
Y29tIj5uZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBh
bSBoYXBweSB3aXRoIHRoaXMgcHJvcG9zZWQgd29yZGluZy4gVGhhbmtzIGZvciB1cGRhdGluZyBp
dC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCBOZWls
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMSBNYXkg
MjAyMCwgYXQgMTk6NTIsIEFhcm9uIFBhcmVja2kgJmx0OzxhIGhyZWY9Im1haWx0bzphYXJvbkBw
YXJlY2tpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFhcm9uQHBhcmVja2kuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Mg
Zm9yIHRoZSBsaXZlbHkgZGlzY3Vzc2lvbiBhcm91bmQgUEtDRSBpbiBPQXV0aCAyLjEgZXZlcnlv
bmUhJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X
ZSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0LCB3aGljaCBpcyBhIHNs
aWdodCB2YXJpYXRpb24gZnJvbSB0aGUgdGV4dCBOZWlsIHByb3Bvc2VkLiBUaGlzIHdvdWxkIHJl
cGxhY2UgdGhlIHBhcmFncmFwaCBpbiA0LjEuMi4xICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtcGFyZWNraS1vYXV0aC12Mi0xLTAyI3NlY3Rpb24tNC4xLjIuMSIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXJlY2tp
LW9hdXRoLXYyLTEtMDIjc2VjdGlvbi00LjEuMi4xPC9hPikNCiB0aGF0IGJlZ2lucyB3aXRoICZx
dW90O0lmIHRoZSBjbGllbnQgZG9lcyBub3Qgc2VuZCB0aGUgJnF1b3Q7Y29kZV9jaGFsbGVuZ2Um
cXVvdDsgaW4gdGhlIHJlcXVlc3QuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7QW4gQVMgTVVTVCByZWplY3QgcmVxdWVz
dHMgd2l0aG91dCBhIGNvZGVfY2hhbGxlbmdlIGZyb20gcHVibGljIGNsaWVudHMsIGFuZCBNVVNU
IHJlamVjdCBzdWNoIHJlcXVlc3RzIGZyb20gb3RoZXIgY2xpZW50cyB1bmxlc3MgdGhlcmUgaXMg
cmVhc29uYWJsZSBhc3N1cmFuY2UgdGhhdCB0aGUgY2xpZW50IG1pdGlnYXRlcyBhdXRob3JpemF0
aW9uIGNvZGUgaW5qZWN0aW9uIGluIG90aGVyIHdheXMuIFNlZSBzZWN0aW9uDQogOS43IGZvciBk
ZXRhaWxzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5TZWN0aW9uIDkuNyBpcyB3aGVyZSB0aGUgbnVhbmNlcyBvZiBQS0NFIHZzIG5v
bmNlIGFyZSBkZXNjcmliZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFzIE5laWwgZGVzY3JpYmVkLCB3ZSBiZWxpZXZlIHRoaXMgd2lsbCBh
bGxvdyBBU3MgdG8gc3VwcG9ydCBib3RoIE9BdXRoIDIuMCBhbmQgMi4xIGNsaWVudHMgc2ltdWx0
YW5lb3VzbHkuIFRoZSBjaGFuZ2UgZnJvbSBOZWlsJ3MgdGV4dCBpcyB0aGUgY2xhcmlmaWNhdGlv
biBvZiB3aGljaCB0aHJlYXRzLCBhbmQgY2hhbmdpbmcgdG8gTVVTVCBpbnN0ZWFkIG9mIFNIT1VM
RC4gVGhlICZxdW90O01VU1QuLi51bmxlc3MmcXVvdDsgaXMNCiBtb3JlIHNwZWNpZmljIHRoYW4g
JnF1b3Q7U0hPVUxEJnF1b3Q7LCBhbmQgc2luY2Ugd2UgYXJlIGFscmVhZHkgZGVzY3JpYmluZyB0
aGUgZXhwbGljaXQgZXhjZXB0aW9uIHRvIHRoZSBydWxlLCBpdCdzIG1vcmUgY2xlYXIgYXMgYSBN
VVNUIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkFhcm9uIFBhcmVja2k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_MN2PR00MB068633B7B72E5416AA8984D1F5BE0MN2PR00MB0686namp_--


From nobody Mon May 11 17:24:48 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9653A0DDC for ; Mon, 11 May 2020 17:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nPmpiahvx78 for ; Mon, 11 May 2020 17:24:44 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C3C3A0DD8 for ; Mon, 11 May 2020 17:24:44 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id f6so5332464pgm.1 for ; Mon, 11 May 2020 17:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=VdcSVqED1Y1vkuQlbbjRyMnaTNPMd8PxAfXX5bNjR0Y=; b=pYeKo2PyfNXNxerepcX+xywnsqrc5pHTs8gPWxV4w4C4o4UchvTn4gVenquedahNID bXCkpKDlpIFwpIiyWhLLDUlNF8rXnjbGHHGlJiMKUFEKHm7mnssVxRwx79cuSkspCZ15 Gjxr1brn9f6wK4Ro6PCwhw61psR4KeE12FwZAKiZg0/hmA7JjkTBOT2VLqVhGmbb/Yre TqCAUct4gYBjNVkxWTLLxrjNQMtFaQtwhGkoyZhQRUat4tmZZMBpuTCLZYtaSgeRV3aX eY2s8/OEfXV1EA07ePCXZKbYU0QiQYEICuLE+gsHKc+WnRI/3ZjpPgJ/x2Q0bW9pRZBo nxmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=VdcSVqED1Y1vkuQlbbjRyMnaTNPMd8PxAfXX5bNjR0Y=; b=Vzo1mw3u9mGNt4/MHyT2QCQZ7KdJHScr3X8pQGrcqxp8LFHspfG5x1IuAAvRf5qp8n vbMgzsG6lzx7pqJYGo+hQEYNOAQoJrh4RGsD+zdiotK7CPtErFzUCub88OhZYhXgB/DJ gavywh5kTFF61Qpf4RK+LLi6RxVipjGwrQIr5XX1M96UsMmDdyA8fyzqCPecNpbtFJDJ b+VjnBIfz6rrKI3ekejyUNbi543IVjwLLL8FbXUEEah8qymm32wN9I1TIhBI+E2NWnik 3tiKC1knh1GnOdoFTHG1UUvFQijBqkwiHNeLscRCdX83H8HAcGwving4ixlq9ZBMBWh9 KzEQ==
X-Gm-Message-State: AGi0PuYqs55f7irqd1Gf2hNb2ighMWMYSjhq5PygcYHdKnBleK/jRcwj 7ZzNElEyD9Xypo1vuDLO0nMqdA==
X-Google-Smtp-Source: APiQypICXqRrhpziDSEUgl4jCoHZwvcMVZfVkyWJrmaA0VbrABV1aDDih+h2W/k5jyeXkTdbcT3LIw==
X-Received: by 2002:a62:ee02:: with SMTP id e2mr17900570pfi.161.1589243083641;  Mon, 11 May 2020 17:24:43 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id g199sm490761pfb.95.2020.05.11.17.24.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 17:24:42 -0700 (PDT)
From: Vittorio Bertocci 
To: Jared Jennings , Denis 
CC: Benjamin Kaduk , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AWVjNzMz1Wh1JFmMLTwMf11UWdvKNjAxNzIx3/WxUgCABgjfgIAATU+AgAc5EACAA+g5AIAAD6KAgAC26Kk=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 12 May 2020 00:24:40 +0000
Message-ID: 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 00:24:47 -0000

--_000_MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thank you Jared for your comment!
I have to admit I have been very tempted to go that route, mostly for movin=
g things forward, but I still think we=92d do the reader a disservice by re=
laxing the language there.
Real world scenarios are full of situations where additional assumptions ca=
n lower dangers that must be taken in consideration in the general case, wh=
ich might make less of a risk going against the spec in those particular ci=
rcumstances, but their existence doesn=92t warrant relaxing guidance for th=
e general case. A concrete example: I worked on scenarios where resource se=
rvers wanted to guarantee some degree of business continuity in case of AS =
outage, which boiled down to RS=92 willingness to accept ATs past their dec=
lared expiration time, on the condition that the AS outage condition was de=
tectable and the staleness of the AT didn=92t cross a tolerance threshold. =
The business scenario made sense, and the implementer was within their righ=
t in deciding that disregarding exp in those circumstances was acceptable. =
Nonetheless, I would not argue that given the existence of that scenario, r=
fc7519 should turn its MUST NOT into a SHOULD NOT.
There might be circumstances in which the stars align and it is safe for a =
client to inspect the AT, but in the general case that=92s not true (this h=
as been covered in details in the various threads on the topic). Also note,=
 the fact that the client (as the application code) is banned from doing th=
at inspection doesn=92t mean that the solution as a whole cannot do it. Dev=
elopers can examine network traces, or use any other mechanism available in=
 their particular circumstances to inspect traffic that are out of scope fo=
r this specification, and that would give them in practice the oversight di=
scussed here where possible. The specification doesn=92t aim at preventing =
that inspection in general, but it does aim at ensuring that the ability to=
 do perform that is excluded from the contract between the roles described =
in OAuth2, so that any violation is either understood to be high bar, or th=
e logic meant to perform those checks is implemented outside of the client =
code itself, preserving the protocol invariants and protecting developers f=
rom one of the most painful production issues I have observed in many years=
 of real life use of JWT ATs.
Ultimately, the latter part is one of the reasons for which I have a hard t=
ime relaxing this part, whereas pretty easily relaxed constraints on other =
areas where my initial position was more strict (multiple resources in audi=
ence, etc). I know this to be very painful if not addressed correctly, and =
the only arguments against it appear to be more about principle than about =
concrete scenarios, expressive power or security.

From: Jared Jennings 
Date: Monday, May 11, 2020 at 06:30
To: Denis 
Cc: Benjamin Kaduk , Vittorio Bertocci , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"

If I may, step in and offer a suggestion.

What if instead of "MUST NOT" replace with "SHOULD NOT"?

To me, (and this might be me), but MUST NOT describes a violation. As in I =
broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a=
 guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the toke=
n, the risk is therefore known and on the "implementer" of the inspection.

Jared


On Mon, May 11, 2020 at 7:34 AM Denis > wrote:
Hi Benjamin,

We are making progress since we now understand better each other. You wrote=
 several sentences on which I agree:
"I do in fact agree that token inspection by a client can be useful in at l=
east some situations".

"I fully support having privacy considerations sections that discuss the pr=
ivacy properties of the protocol in question,
  even including aspects that are currently lacking.

"I do not believe that a JWT profile for OAuth use is the place to make cha=
nges to the core OAuth protocol that improve its privacy properties".
I also accept your apologies.

RFC 6749 is quite clear in section 1.4 that "The string [access token] is u=
sually opaque to the client".
However, it does not mean that : "The client MUST NOT inspect the content o=
f the access token".
I believe the wording I proposed corresponds to the reality:
There is no guarantee that token inspection can always be performed.

--_000_MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Thank you Jared for your comment!


I have to admit I have been very tempted to go that =
route, mostly for moving things forward, but I still think we=92d do the re=
ader a disservice by relaxing the language there.


Real world scenarios are full of situations where ad=
ditional assumptions can lower dangers that must be taken in consideration =
in the general case, which might make less of a risk going against the spec
in those particular circumstances, but their existence doesn=92t war=
rant relaxing guidance for the general case. A concrete example: I worked o=
n scenarios where resource servers wanted to guarantee some degree of busin=
ess continuity in case of AS outage,
 which boiled down to RS=92 willingness to accept ATs past their declared e=
xpiration time, on the condition that the AS outage condition was detectabl=
e and the staleness of the AT didn=92t cross a tolerance threshold. The bus=
iness scenario made sense, and the implementer
 was within their right in deciding that disregarding exp in those circumst=
ances was acceptable. Nonetheless, I would not argue that given the existen=
ce of that scenario, rfc7519 should turn its MUST NOT into a SHOULD NOT.



There might be circumstances in which the stars alig=
n and it is safe for a client to inspect the AT, but in the general case th=
at=92s not true (this has been covered in details in the various threads on=
 the topic). Also note, the fact that
 the client (as the application code) is banned from doing that inspection =
doesn=92t mean that the solution as a whole cannot do it. Developers can ex=
amine network traces, or use any other mechanism available in their particu=
lar circumstances to inspect traffic
 that are out of scope for this specification, and that would give them in =
practice the oversight discussed here where possible. The specification doe=
sn=92t aim at preventing that inspection in general, but it does aim at ens=
uring that the ability to do perform
 that is excluded from the contract between the roles described in OAuth2, =
so that any violation is either understood to be high bar, or the logic mea=
nt to perform those checks is implemented outside of the client code itself=
, preserving the protocol invariants
 and protecting developers from one of the most painful production issues I=
 have observed in many years of real life use of JWT ATs.


Ultimately, the latter part is one of the reasons fo=
r which I have a hard time relaxing this part, whereas pretty easily relaxe=
d constraints on other areas where my initial position was more strict (mul=
tiple resources in audience, etc).
 I know this to be very painful if not addressed correctly, and the only ar=
guments against it appear to be more about principle than about concrete sc=
enarios, expressive power or security.     <=
/p>

 




From=
: Jared Jennings &l=
t;jaredljennings@gmail.com>

Date: Monday, May 11, 2020 at 06:30

To: Denis <denis.ietf@free.fr>

Cc: Benjamin Kaduk <kaduk@mit.edu>, Vittorio Bertocci <vitt=
orio.bertocci@auth0.com>, "oauth@ietf.org" <oauth@ietf.org&=
gt;

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






 








If I may, step in and offer a suggestion.=







 






What if instead of "MUST NOT" replace with=
 "SHOULD NOT"?






 






To me, (and this might be me), but MUST NOT describe=
s a violation. As in I broke the law. Conversely, I interpret, "SHOULD=
 NOT" as a recommendation, a guideline, best practice, etc.=







 






If then the sentence went on to explain why you shou=
ld not inspect the token, the risk is therefore known and on the "impl=
ementer" of the inspection.






 












Jared








 




 






On Mon, May 11, 2020 at 7:34 AM Denis <denis.ietf@free.fr> wrote:









Hi Benjamin,






 






We are making progress since we now understand bette=
r each other. You wrote several sentences on which I agree:








"I do in fact agree that token inspection by a =
client can be useful in at least some situations".







 






"I fully support having privacy considerations =
sections that discuss the privacy properties of the protocol in question,
  even including aspects that are currently lacking.=









"I do not believe that a JWT profile for OAuth use is the place to mak=
e changes to the core OAuth protocol that improve its privacy properties&qu=
ot;.








I also accept your apologies.






 






RFC 6749 is quite clear in section 1.4 that "Th=
e string [access token]
is usually opaque to the client". 

However, it does not mean that : "The client MUST NOT inspect t=
he content of the access token".






I believe the wording I proposed corresponds to the =
reality:









There is no guarantee that token inspection can alwa=
ys be performed.


















--_000_MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0MWHPR19MB1501namp_--


From nobody Mon May 11 18:12:57 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC30C3A0C2D for ; Mon, 11 May 2020 18:12:55 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA4h90Gj_LWO for ; Mon, 11 May 2020 18:12:54 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C023A0C27 for ; Mon, 11 May 2020 18:12:54 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id j8so12044027iog.13 for ; Mon, 11 May 2020 18:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=d9gk6Z+qCb6CLA34/eI4+Mo7JDB26gp6gcCx9EAu8KY=; b=DV05BysJk4C2GyNZHlIX9EzMAY/MThImuobU6YscdNLct+tFXW6t8KXD+PnVQKDAwu 3wNYS1YzPy5bRTx2IqX3O/9XDlkS9hgTl07rHcDd9peq5tV5/wJf6TJIDE6NQrYYFs6z IwIYVn5EFK+JoOPNelLz9B7TkCyN9bo4wZuv9WgnRRf9hJh+/Zhmn1NC8TAqExN3JG62 hRZR/NOxu3VGyekr+1GSwP8q6cl6gHf9ojTi8HBR7CnzTrw/rQ/Qvicoz8ALW0OFO76Q fy0R8ZNCxRjGVDnwQANISg3psog13Y+W7lr0qcAJnuni8hX4gCAd0g4FscYBdUG6BPfj 2HWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d9gk6Z+qCb6CLA34/eI4+Mo7JDB26gp6gcCx9EAu8KY=; b=EovZID3HJyEPuz55PHPfemHJjSIOWiP6PeOWBMgPL/LsFwEnbmqdFtKFefC79Km78W SjkUNp16IX5poiBfhG19pYwM/3GZOD0v84NyTc/8RME/CjOJ5z3i1PUUaNLJbPDoFlHZ K+uMLtlKA5IIy5dp2ydpfy64ug4e4JzuQ+YwbXfZPb2mQ/ObJSpOQbBI5t/J85JgtfdG 5oJCU4t51wmUp5n9rvB2SkS6WiR144IRsg3AIL7aiTG9TyA75I8K+UIwvoPI/rzsJHVD DaqXxIFLUE+I9hrZo0h/IGvVfPUYMdNwJGRiXu72JuRX0Pp2IqTuFMcNfVhz73QoFCQp 057g==
X-Gm-Message-State: AGi0PubgbTyA1BdlF+ZkN4bbUTp0uTaRty0MPcOBxkZHghiOXg+y/RRI lbSE4vmbqdizuyIPm+4Cn6Ap8ZBDOd4=
X-Google-Smtp-Source: APiQypKs7+i7hoPdJvfb2MaBHNZyJ+4IspRSqT+REyeFRObn49sf/Cqb7aL3d8T+rrFUUJcJBPv/+A==
X-Received: by 2002:a6b:5109:: with SMTP id f9mr18450656iob.125.1589245972905;  Mon, 11 May 2020 18:12:52 -0700 (PDT)
Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id h9sm58489ioa.6.2020.05.11.18.12.51 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 18:12:52 -0700 (PDT)
Received: by mail-io1-f52.google.com with SMTP id s10so12057610iog.7 for ; Mon, 11 May 2020 18:12:51 -0700 (PDT)
X-Received: by 2002:a02:c998:: with SMTP id b24mr18015493jap.23.1589245971364;  Mon, 11 May 2020 18:12:51 -0700 (PDT)
MIME-Version: 1.0
From: Aaron Parecki 
Date: Mon, 11 May 2020 18:12:40 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: John Bradley , OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000095864c05a56929e3"
Archived-At: 
Subject: [OAUTH-WG] draft-bradley-oauth-jwt-encoded-state-09
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 01:12:56 -0000

--00000000000095864c05a56929e3
Content-Type: text/plain; charset="UTF-8"

Hi John,

I noticed this individual draft expired a little over a year ago. Do you
have any intention of picking up this work again?

https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-09

Thanks!

Aaron Parecki

--00000000000095864c05a56929e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi John,

I noticed this individual draf=
t expired a little over a year ago. Do you have any intention of picking up=
 this work again?


Tha=
nks!

Aaron Parecki

=



--00000000000095864c05a56929e3--


From nobody Mon May 11 19:11:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788D03A0044 for ; Mon, 11 May 2020 19:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuW4hrVfoia0 for ; Mon, 11 May 2020 19:11:14 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48BC23A003D for ; Mon, 11 May 2020 19:11:14 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id h17so4490368wrc.8 for ; Mon, 11 May 2020 19:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=GVYaP2rSCODeASCndPQqHayDGjfkjhtCL6BZ6COBuWA=; b=Rdyyuj7hwu+BuC2gMfdKZN7wrJtF0jrMZMLPppBpCmFoc14HAL+SFfNF7pyjgmK+DG 8HgBHc/w/VfGu9Bf1JJ+V72neVMVNCc4ytemMGZJbBFYmL/a8DKEtFRzZqONy/ZOsEw9 ejpkzYkqRqplYtUZHN6CgDBcAbABgsVHqwzOo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GVYaP2rSCODeASCndPQqHayDGjfkjhtCL6BZ6COBuWA=; b=qoAQctPuBpYeZ1xOaIvdVqLSGK4RgxKXrjkfGgNxzWyiax5HtIpJcntYdUcURxfEBd plT8mqxLLV1ig+z5HsgvRa8Zwjdoj6NjhEdBm+NXqNGltrRSkQqNrl64didO6sCDvr1p 1BZCsqeiXhDsowiaicsQKQ1XsQswzY/QJolbez8FIIXZEhznYy3wSGh5SFJy0pDiUpfR jw3QBwS908nf5BIZpHYharSBhdZm42exJ/OI+IPKPBtyTSrtnpFPEnubJoJ52GO8BhBY Qci1nRnRqNvdVvrRdcMmMxzssXPDf8zIHmTEpXOfDGBl7krbJmRZW9Yq8cRnZo1YBENM aNaw==
X-Gm-Message-State: AGi0PuanK+wwcOrw82R0QZfy2AI2emHa6Rcz3CyIhLEL5sXkbtnZM3YD whycgRw2Y2msFB9aizXEHGg8lUVxCAPHXqukIs2i3d/AUETCuQ==
X-Google-Smtp-Source: APiQypL6j60zeiuSD3JBMSeiZrRLauK+dDXfP0V6E4mMnB9rn/shE98p30B3QqyYH0tZeSOzy9zXeLonn2cEM4ctDN8=
X-Received: by 2002:a5d:684f:: with SMTP id o15mr21480316wrw.89.1589249472309;  Mon, 11 May 2020 19:11:12 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Francis Pouatcha 
Date: Mon, 11 May 2020 22:11:01 -0400
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000041c27e05a569faaf"
Archived-At: 
Subject: [OAUTH-WG] Subject: Re:  Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 02:11:16 -0000

--00000000000041c27e05a569faaf
Content-Type: text/plain; charset="UTF-8"

Hi Aaron,

>
>
> Hi Beena,
>
> This sounds like a great use of the client credentials grant. The password
> grant is being removed from OAuth 2.0 by the Security Best Current
> Practice. Can you clarify what you've found useful about the password grant
> that the client credentials grant doesn't solve?
>
Beena could use the Dynamic Client Registration to have all those devices
registered as oAuth Clients. But this seems to be inconvenient as he
describes.

In the password grant flow, the device holds the password and is not
involved in any interaction with the AS. This keeps the device use case
simple.


>
> Aaron Parecki
>
>
> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
> beenapurushothaman@gmail.com>
> wrote:
>
> > Hi,
> >
> >
> > We have a product with client server architecture where our server
> manages
> > thousands of devices. Each device has a client-piece that talks to the
> > server over SOAP/REST. The client currently uses a HTTP Basic
> > Authentication (unique id and a secret string) for all the calls. The
> > secret string is created when the device enrolls to the server. It is
> > available at the server as well as stored securely on the device. For the
> > rest calls it is the device that is getting authenticated.
> >
> >
> >
> >  Sending the credentials every time is less than ideal and we want to
> move
> > to some tokenized device authentication. We evaluated OpendID Connect
> based
> > on the general recommendation of SSO solution, but the issue is we do not
> > have any user interaction and hence there is no Grant flow that is
> fitting.
> > Hence we evaluated OAuth grant type of which we found Password Grant and
> > Client Credentials Grant is matching our requirement.
> >
> >
> >
> >  In order to use Client Credentials in our use case, we need to do
> dynamic
> > registration for the thousands of devices managed by the server, if IoT
> > comes into picture the number is going to be even higher, which is highly
> > cumbersome to manage.  Also, as per  RFC7591 on dynamic client
> > registration, using access token for registering client is optional too.
> > Even though the Password grant is highly discouraged by the spec, we
> found
> > it to be highly matching with our requirements.
> >
> >
> >
> > But as per the Oauth 2.1 proposal, password grant is going to be
> removed. Can
> > you suggest the way forward for us? I believe we are not a one-off case.
> >
> >
> > Thank You,
> >
> > Beena
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/8873117a/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 139, Issue 45
> **************************************
>


-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

--00000000000041c27e05a569faaf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0Aaron,




Hi Beena,



This sounds like a great use of the client credentials grant. The password<=
br>
grant is being removed from OAuth 2.0 by the Security Best Current

Practice. Can you clarify what you've found useful about the password g=
rant

that the client credentials grant doesn't solve?
B=
eena could use the Dynamic Client Registration to have all those devices re=
gistered as oAuth Clients. But this seems to be inconvenient as he describe=
s.

In the password grant flow, the device holds th=
e password and is not involved in any interaction with the AS. This keeps t=
he device use case simple.=C2=A0
=C2=A0



Aaron Parecki





On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <beenapurushothaman@gmail.com&=
gt;

wrote:



> Hi,

>

>

> We have a product with client server architecture where our server man=
ages

> thousands of devices. Each device has a client-piece that talks to the=


> server over SOAP/REST. The client currently uses a HTTP Basic

> Authentication (unique id and a secret string) for all the calls. The<=
br>
> secret string is created when the device enrolls to the server. It is<=
br>
> available at the server as well as stored securely on the device. For =
the

> rest calls it is the device that is getting authenticated.

>

>

>

>=C2=A0 Sending the credentials every time is less than ideal and we wan=
t to move

> to some tokenized device authentication. We evaluated OpendID Connect =
based

> on the general recommendation of SSO solution, but the issue is we do =
not

> have any user interaction and hence there is no Grant flow that is fit=
ting.

> Hence we evaluated OAuth grant type of which we found Password Grant a=
nd

> Client Credentials Grant is matching our requirement.

>

>

>

>=C2=A0 In order to use Client Credentials in our use case, we need to d=
o dynamic

> registration for the thousands of devices managed by the server, if Io=
T

> comes into picture the number is going to be even higher, which is hig=
hly

> cumbersome to manage.=C2=A0 Also, as per=C2=A0 RFC7591 on dynamic clie=
nt

> registration, using access token for registering client is optional to=
o.

> Even though the Password grant is highly discouraged by the spec, we f=
ound

> it to be highly matching with our requirements.

>

>

>

> But as per the Oauth 2.1 proposal, password grant is going to be remov=
ed. Can

> you suggest the way forward for us? I believe we are not a one-off cas=
e.

>

>

> Thank You,

>

> Beena

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/887311=
7a/attachment.html>



------------------------------



Subject: Digest Footer



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





------------------------------



End of OAuth Digest, Vol 139, Issue 45

**************************************




-- 
Francis Pouatcha
Co-=
Founder and Technical Lead at adorys


--00000000000041c27e05a569faaf--


From nobody Mon May 11 20:00:50 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240C43A08C4 for ; Mon, 11 May 2020 20:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id komPTEZgOZGb for ; Mon, 11 May 2020 20:00:47 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC803A08C3 for ; Mon, 11 May 2020 20:00:46 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id s8so13462028wrt.9 for ; Mon, 11 May 2020 20:00:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:from:date:message-id:subject:to; bh=ofmtoG1tywggCdnYyshUX++DsNcvpM1cO8y11EinJg0=; b=c5WQj8lMwblqW8BFjOpWUkWLHyQ0lZAzHBtUAns5N1z6lfCA8emx562MOqhYZzwLp7 Cf3x4MzXzVogMcqKXZXM35ZoQ1yVHToXjlu9YV8EuWRJopgfUj5TUXnpgv+W1Iml+IvR Y1z1Nh+z9SScwdgiuDKb7Lg9mKtZrYoVUL400=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ofmtoG1tywggCdnYyshUX++DsNcvpM1cO8y11EinJg0=; b=djbAMPNBmD/TdV3JZdLpwsDyqPkB1mAKpYL58kSEtDlokJuePPc7M+5Z3IoqcDzJrD zhxNdmk2UkfhAia9lZ3Ubk19LKNDdmNIV2cpw7LLt4jN0KDnjyStjmKtHtiQAqoaXLkE 5gENO6oOP+RRr5Ups26SAAa2POrjPs3I0ettco71JYTWpuOo9AP78HUtHFReVDypE/EM J9R5jab/U1q6AhPRwdBfB8MjG8GcTrPmgbbqwYA4JBqHvL5q2jsnjDvTMQEiYTKTHEY8 FY90ZIdYFX4qk7zATjZ8YtqiD/UZr9EBDhptnXCuIy6XqtsHtjapwNCkFhAOszjx+ms8 WqRw==
X-Gm-Message-State: AGi0PuYcycpsSJ9ZLrHoT50la0wG3uL5T7tR8ThyuJqOl6fo/zDNKKMw 6cj/3mIV1Elf3IvPzuMeQ7hSHw85KUC/I0BXFzL1uNFVG/X/3A==
X-Google-Smtp-Source: APiQypIHBHBKJoEDzWih1OorgIL8esRAYf2+djdGpyOSxo/qsuhlu+08VO9mIZnRwxxyvjlZ8FG/QWI/akYDy3a9H80=
X-Received: by 2002:adf:f34e:: with SMTP id e14mr18026178wrp.371.1589252444722;  Mon, 11 May 2020 20:00:44 -0700 (PDT)
MIME-Version: 1.0
From: Francis Pouatcha 
Date: Mon, 11 May 2020 23:00:34 -0400
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000006d29ad05a56aabce"
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 03:00:49 -0000

--0000000000006d29ad05a56aabce
Content-Type: text/plain; charset="UTF-8"

I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password
Credentials) with the following reasoning:

Auth Code Grant:
There are  many use cases on the market where redirection based flows do
not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the
complexity of user agents on non controllable client devices still make
user agent redirection a challenge.

Client Credentials Grant:
Requires the registration of an oAuth client.
- Citing the iot device use cases Beena which do not have a comfortable way
to have iot devices register with AS.
- This is a registration flow for the oAuth client role  and for the RO
(Resource Owner). Remember resource owner credentials might be sourced from
system external to the AS  like company's LDAP. oAuth Client Credentials
are generally managed by the AS.
For these reasons, we shall not use Client Credential Grant to manage RO
authorization.

ROPC:
Having an oAuth Client proxy the auth request of the RO to the AS only
presents a security risk if the oAuth Client is a third party application.
Therefore, the decision on whether to accept ROPC for a specified client
shall be left to the AS. Discarding this use case will take a lot of
business from oAuth servers back to the old market.

Beside this, I mentioned in my previous post that there are use cases in
the market where permanent passwords are replaced with one time passwords.

A lot of work is also being done in the direction of having the RO send
signed proof of ownership to the AS through the ROPC  flow using the
password field.

Therefore, I am ok with raising the attention of  implementers the same way
we are doing with PKCE,  mentioning that ROPC  must only be used if  AS /
oAuth Client can guarantee security of the RO credentials exposed to the
oAuth Client.

/Francis
-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

--0000000000006d29ad05a56aabce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am against=C2=A0OAuth =
2.1 discarding the use of ROPC (Resource Owner Password Credentials) with t=
he following=C2=A0reasoning:

Auth Code=
 Grant:
There are=C2=A0 many use cases on the market =
where redirection based flows=C2=A0do not work. As=C2=A0 we see in the &quo=
t;OAuth 2.1 - require PKCE?" thread, the complexity of user agents on =
non controllable=C2=A0client devices still make user agent redirection a ch=
allenge.=C2=A0

Client Credentials Gran=
t:
Requires the registration of an oAuth client.
- Citing the iot device use cases Beena which do not have=
 a comfortable way to have iot devices register with AS.
- This i=
s a registration flow for the oAuth client role=C2=A0 and for the RO (Resou=
rce Owner). Remember resource owner credentials might be sourced from syste=
m external to the AS=C2=A0 like company's LDAP. oAuth Client Credential=
s are generally=C2=A0managed by the AS.
For these reasons, we sha=
ll not use Client Credential Grant to manage RO authorization.
ROPC:
Having an oAuth Client proxy the auth request =
of the RO to the AS only presents a security risk if the oAuth Client is a =
third party application. Therefore, the decision on whether to accept=C2=A0=
ROPC for a specified client shall be left to the AS. Discarding this use ca=
se will take a lot of business from oAuth servers back to the old market.

Beside this, I mentioned in my previous post that t=
here are use cases in the market where permanent passwords are replaced wit=
h one time passwords.

A lot of work is also being =
done in the direction of having the RO send signed proof of ownership to th=
e AS through the ROPC=C2=A0 flow using the password field.

Therefore, I am ok with raising the attentio=
n of=C2=A0 implementers=C2=A0the same way we are doing with PKCE,=C2=A0 men=
tioning that ROPC=C2=A0 must only be used if=C2=A0 AS / oAuth Client can gu=
arantee security of the RO credentials exposed to the oAuth Client.=C2=A0

/Francis
-- 
<=
div dir=3D"ltr">
Francis Pouatcha
=
Co-Founder and Technical Lead at adorys


--0000000000006d29ad05a56aabce--


From nobody Mon May 11 20:14:38 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0653A0966 for ; Mon, 11 May 2020 20:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40QOjkKX1K9N for ; Mon, 11 May 2020 20:14:34 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6A03A0956 for ; Mon, 11 May 2020 20:14:34 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id b6so11124301qkh.11 for ; Mon, 11 May 2020 20:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=c5Ur1ziVec+PQhHOPVN+H7zAfE5c0d7iHp5C0Kjo2qY=; b=GookgpnyZoZlnR98mSjxzWGZt9TAMaxknZ/OVN0drF5b6QCP4mi9nd7G+iknS8gp7H y3V32AlpFzY9BI9Adyeh9ps1rZR37dwQvx2Qe4WmsaAOJ6oCiItlo02dJgsxzEfdlQlO ZLvaudw1bmaMH/SJNZzdXL1WJYNrBR0mAdFALn2y4a5Lb/tboS2i6m9jYIPnmNGVnpra eavG/n98pja3FHZlDgzgkEsplu/7x6O2E/mMRXW9ZRI5AEkCqwm0zLP0TzxwqWILHQYL ezV8vi/2R9K5C9nf6KuPt1PZmdil4RljE2n962dpSxgg2qECWhJP6yRNVsePZFo9tpwP qkTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=c5Ur1ziVec+PQhHOPVN+H7zAfE5c0d7iHp5C0Kjo2qY=; b=VsTkhJUD4aT0P8SW2Cp+0mibi7huYL4Xg8PaKifhPD3R14E6IXv8uNvz2lRcW7f4vY 1xjHdUjMPcZ8OrzwrtvtOCa27f5nMRGv2cztinZr2StXXg3gFCk8N07KHJuOZaoVGFW3 UHFGCpmc2u8WCJvh4MvNYFbkQfWwebyEr8YqVvu1pMUcWATHumhLsJeWL4eRVe9XprSC k1O2deZa5O3hVqTnbHeoHNO8wcN0ycss9YXZTuH1D1A4Px58jwkKoigMZ2E2FLhsr4Tj cyL9Wy6c3sols5xOS7liGZYy1OuXtT7SApKKbapFB8SF+BzSCLBFMQ7CHeax0hAB5n/z i9NQ==
X-Gm-Message-State: AGi0PuaJCEf2D62dFIFp0s34cuE3my3VBa/LnDsyOjCfL7UpjEWNBqax uO22W+AXXF3UWFtu1qXqO2g=
X-Google-Smtp-Source: APiQypLxdkGmVxZzjFMCK+DcUPhlIXxtWgnwrVoxN30X+RU26yD2f92n1/XJsCa6oTLyZyAKoggx9Q==
X-Received: by 2002:a37:dc6:: with SMTP id 189mr7653213qkn.279.1589253273152;  Mon, 11 May 2020 20:14:33 -0700 (PDT)
Received: from jareds-mbp-2.lan ([72.214.174.119]) by smtp.gmail.com with ESMTPSA id j36sm10462643qta.71.2020.05.11.20.14.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 20:14:32 -0700 (PDT)
From: Jared Jennings 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_19CF74DC-52E5-4C24-A6A6-DD9E6F26F168"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 11 May 2020 22:14:30 -0500
In-Reply-To: 
Cc: Denis , Benjamin Kaduk , "oauth@ietf.org" 
To: Vittorio Bertocci 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 03:14:37 -0000

--Apple-Mail=_19CF74DC-52E5-4C24-A6A6-DD9E6F26F168
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide =
implementors from making bad choices, not from a security perspective. =
Meaning, it's not a security risk that a client does inspect or analyze =
the token. Instead, it's is an interop issue and thus we are guiding =
implementors to never assume or expect the token format to be consistent =
or of a expected format, for various reasons. I kinda know the answer to =
this question, but I am kinda asking this way to help restate the intent =
of the "topic" and maybe help guide to a wording that works for =
everyone.

For example, as a consultant, it can be very helpful to know how to =
decompile or inspect an "Object", but at the same time knowing that such =
a method or practice should never be used in production.

Jared


> On May 11, 2020, at 19:24, Vittorio Bertocci =
 wrote:
>=20
> Real world scenarios are full of situations where additional =
assumptions can lower dangers that must be taken in consideration in the =
general case, which might make less of a risk going against the specin =
those particular circumstances, but their existence doesn=E2=80=99t =
warrant relaxing guidance for the general case. A concrete example: I =
worked on scenarios where resource servers wanted to guarantee some =
degree of business continuity in case of AS outage, which boiled down to =
RS=E2=80=99 willingness to accept ATs past their declared expiration =
time, on the condition that the AS outage condition was detectable and =
the staleness of the AT didn=E2=80=99t cross a tolerance threshold. The =
business scenario made sense, and the implementer was within their right =
in deciding that disregarding exp in those circumstances was acceptable. =
Nonetheless, I would not argue that given the existence of that =
scenario, rfc7519 should turn its MUST NOT into a SHOULD NOT.
>=20


--Apple-Mail=_19CF74DC-52E5-4C24-A6A6-DD9E6F26F168
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Vittorio,

Yeah, this =
does make a bit of sense. So, the goal is to guide implementors from =
making bad choices, not from a security perspective. Meaning, it's not a =
security risk that a client does inspect or analyze the token. Instead, =
it's is an interop issue and thus we are guiding implementors to never =
assume or expect the token format to be consistent or of a expected =
format, for various reasons. I kinda know the answer to this question, =
but I am kinda asking this way to help restate the intent of the "topic" =
and maybe help guide to a wording that works for everyone.

For example, as a =
consultant, it can be very helpful to know how to decompile or inspect =
an "Object", but at the same time knowing that such a method or practice =
should never be used in production.

Jared


On May 11, 2020, at 19:24, Vittorio Bertocci <vittorio.bertocci@auth0.com> wrote:

Real world scenarios are full of situations where =
additional assumptions can lower dangers that must be taken in =
consideration in the general case, which might make less of a risk going =
against the specin those particular circumstances, but =
their existence doesn=E2=80=99t warrant relaxing guidance for the =
general case. A concrete example: I worked on scenarios where resource =
servers wanted to guarantee some degree of business continuity in case =
of AS outage, which boiled down to RS=E2=80=99 willingness to accept ATs =
past their declared expiration time, on the condition that the AS outage =
condition was detectable and the staleness of the AT didn=E2=80=99t =
cross a tolerance threshold. The business scenario made sense, and the =
implementer was within their right in deciding that disregarding exp in =
those circumstances was acceptable. Nonetheless, I would not argue that =
given the existence of that scenario, rfc7519 should turn its MUST NOT =
into a SHOULD NOT.


=

--Apple-Mail=_19CF74DC-52E5-4C24-A6A6-DD9E6F26F168--


From nobody Mon May 11 20:17:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B693A0973 for ; Mon, 11 May 2020 20:17:22 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2Kks8sYD5yB for ; Mon, 11 May 2020 20:17:20 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6C33A0966 for ; Mon, 11 May 2020 20:17:20 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id t12so10803786ile.9 for ; Mon, 11 May 2020 20:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pp/CDOwXN1fYCs+l7mbvxWj4vnY5fw6m2U/7/80ZsSk=; b=cxqenVFaUVrrTcepTaAgWmege8q0+vnqpDOYWFtKnAl4JBlfJmF6zVFXJ65UdHB8uL /2fxS7pH8Qnmw2geXpw0qgh8/b4DYcXFkgfOqVlWuz3+jzSe2Zz7oZAEDX3HvCu2E2w/ WBh/sHZ004g1gAXoMjkcdq8ws33qa8wN3S5zbxK3M7vqrdt5xS7C1GOQAceX5kGq46Wf wr8ZrNDByE6qIjDUa6tovVNtCzbtJrRHebrHSI2jbEn8gTw1KYEzKOsf4v+o/DP/zNaN /6FoIGFhbC5J4V76ppHmt19LMsG+BUykf3I/Xx+hDkDTzBZ0fYs5ZTGjASZTXDtaxbrc IW+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pp/CDOwXN1fYCs+l7mbvxWj4vnY5fw6m2U/7/80ZsSk=; b=dAEYoButf/d12LwQA6rwGFYLvlC1MLAIKjgFngDG5fyWC3NSEw06Vhz90K3MWawv3R 7npLJJuhmZNmcjpeh2jemOgFfT8XdPK+nexBgOHWsiIjO2k7V2zU8zI0o96N3hk6twfn eRR2HcqAeFTF5kkcuPi+slCjBjc19euI92+oI+ujGXC/RQqQWOk9G0jCaTmgfQu28hCn F4MaEswZR3cBea91pJi8G5XlulKeFgtEOnVMneD3INWkKqtqooUAixHJO9M7A4I/AeVU If/e/Mm/6GpnaR1DVKy51XTQhuYGoJ0qOLm/8uVWKHdme0K6lRwqmaOgOB0nQd1YEi49 Sdog==
X-Gm-Message-State: AGi0PubqRhF6zTAQAYY+lutLnvkMYDHse85zXRwfxH3nVZXVey1ResQN OkQxfa6ligTxGVXn7A5GnypoAHf9c8qbEg==
X-Google-Smtp-Source: APiQypLqIKKMfbOzB3+GmUkrPzYv4CQ86Sbuh/ycy6/nXTV7eniOr5zPy1yvcgFZrA8p5I+yBplllA==
X-Received: by 2002:a05:6e02:66c:: with SMTP id l12mr8844983ilt.289.1589253438802;  Mon, 11 May 2020 20:17:18 -0700 (PDT)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id p10sm5917189ilp.29.2020.05.11.20.17.17 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 20:17:17 -0700 (PDT)
Received: by mail-io1-f41.google.com with SMTP id u11so12314278iow.4 for ; Mon, 11 May 2020 20:17:17 -0700 (PDT)
X-Received: by 2002:a05:6638:277:: with SMTP id x23mr1166662jaq.122.1589253437328;  Mon, 11 May 2020 20:17:17 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Aaron Parecki 
Date: Mon, 11 May 2020 20:17:06 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Francis Pouatcha 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000097109105a56ae61c"
Archived-At: 
Subject: Re: [OAUTH-WG] Subject: Re: Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 03:17:23 -0000

--00000000000097109105a56ae61c
Content-Type: text/plain; charset="UTF-8"

> In the password grant flow, the device holds the password and is not
involved in any interaction with the AS. This keeps the device use case
simple.

I'm not sure what you mean by this. If you're suggesting that the client
never interacts with the AS and sends the password directly to the resource
server, that's never been part of OAuth. That's specifically the situation
OAuth was created to avoid.

The password grant gave the client a way to exchange the password for an
access token by sending it first to the AS. As such, the difference between
the password grant and the client credentials grant is the presence of two
additional parameters in the request to the AS:

    POST /token
    grant_type=client_credentials
    &client_id=X
    &client_secret=Y

vs

    POST /token
    grant_type=password
    &client_id=X
    &client_secret=Y
    &username=Z
    &password=Q

The response of both of these is an access token, which the client then
sends to the resource server.

> In order to use Client Credentials in our use case, we need to do dynamic
> registration for the thousands of devices managed by the server

Regardless of which of these two methods you use, the client's credentials
(either client ID/secret or username/password) needs to be enrolled at the
AS in order to get an access token. That's why I'm saying there isn't a
functional difference and trying to clarify why you think the password
grant is a better fit for your situation. In reality for your use case it
seems it is only adding complexity to the situation compared to just using
a client ID and secret.

Aaron Parecki


On Mon, May 11, 2020 at 7:11 PM Francis Pouatcha  wrote:

> Hi Aaron,
>
>>
>>
>> Hi Beena,
>>
>> This sounds like a great use of the client credentials grant. The password
>> grant is being removed from OAuth 2.0 by the Security Best Current
>> Practice. Can you clarify what you've found useful about the password
>> grant
>> that the client credentials grant doesn't solve?
>>
> Beena could use the Dynamic Client Registration to have all those devices
> registered as oAuth Clients. But this seems to be inconvenient as he
> describes.
>
> In the password grant flow, the device holds the password and is not
> involved in any interaction with the AS. This keeps the device use case
> simple.
>
>
>>
>> Aaron Parecki
>>
>>
>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>> beenapurushothaman@gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> >
>> > We have a product with client server architecture where our server
>> manages
>> > thousands of devices. Each device has a client-piece that talks to the
>> > server over SOAP/REST. The client currently uses a HTTP Basic
>> > Authentication (unique id and a secret string) for all the calls. The
>> > secret string is created when the device enrolls to the server. It is
>> > available at the server as well as stored securely on the device. For
>> the
>> > rest calls it is the device that is getting authenticated.
>> >
>> >
>> >
>> >  Sending the credentials every time is less than ideal and we want to
>> move
>> > to some tokenized device authentication. We evaluated OpendID Connect
>> based
>> > on the general recommendation of SSO solution, but the issue is we do
>> not
>> > have any user interaction and hence there is no Grant flow that is
>> fitting.
>> > Hence we evaluated OAuth grant type of which we found Password Grant and
>> > Client Credentials Grant is matching our requirement.
>> >
>> >
>> >
>> >  In order to use Client Credentials in our use case, we need to do
>> dynamic
>> > registration for the thousands of devices managed by the server, if IoT
>> > comes into picture the number is going to be even higher, which is
>> highly
>> > cumbersome to manage.  Also, as per  RFC7591 on dynamic client
>> > registration, using access token for registering client is optional too.
>> > Even though the Password grant is highly discouraged by the spec, we
>> found
>> > it to be highly matching with our requirements.
>> >
>> >
>> >
>> > But as per the Oauth 2.1 proposal, password grant is going to be
>> removed. Can
>> > you suggest the way forward for us? I believe we are not a one-off case.
>> >
>> >
>> > Thank You,
>> >
>> > Beena
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/8873117a/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ------------------------------
>>
>> End of OAuth Digest, Vol 139, Issue 45
>> **************************************
>>
>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000097109105a56ae61c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> In the password grant flow, the device holds the pass=
word and is not involved in any interaction with the AS. This keeps the dev=
ice use case simple.

I'm not sure what you mean by t=
his. If you're suggesting that the client never interacts with the AS a=
nd sends the password directly to the resource server, that's never bee=
n part of OAuth. That's specifically the situation OAuth was created to=
 avoid.

The password grant gave the client a way t=
o exchange the password for an access token by sending it first to the AS. =
As such, the difference between the password grant and the client credentia=
ls grant is the presence of two additional parameters in the request to the=
 AS:

=C2=A0 =C2=A0 POST /token
=C2=A0 =
=C2=A0 grant_type=3Dclient_credentials
=C2=A0 =C2=A0 &client_=
id=3DX
=C2=A0 =C2=A0 &client_secret=3DY

<=
div>vs=C2=A0

=C2=A0 =C2=A0 POST /token
=
=C2=A0 =C2=A0 grant_type=3Dpassword
=C2=A0 =C2=A0 &client_id=
=3DX
=C2=A0 =C2=A0 &client_secret=3DY
=C2=A0 =C2=A0=
 &username=3DZ
=C2=A0 =C2=A0 &password=3DQ

=

The response of both of these is an access token, which the clie=
nt then sends to the resource server.

> In orde=
r to use Client Credentials in our use case, we need to do dynamic
> =
registration for the thousands of devices managed by the server

Regardless of which of these two methods you use, the cli=
ent's credentials (either client ID/secret or username/password) needs =
to be enrolled at the AS in order to get an access token. That's why I&=
#39;m saying there isn't a functional difference and trying to clarify =
why you think the password grant is a better fit for your situation. In rea=
lity for your use case it seems it is only adding complexity to the situati=
on compared to just using a client ID and secret.

=
Aaron Parecki


On Mon, May 11, 2020 at 7:11 PM Francis P=
ouatcha <fpo=3D40adorsys.=
de@dmarc.ietf.org> wrote:
Hi=C2=A0Aaron,




Hi Beena,



This sounds like a great use of the client credentials grant. The password<=
br>
grant is being removed from OAuth 2.0 by the Security Best Current

Practice. Can you clarify what you've found useful about the password g=
rant

that the client credentials grant doesn't solve?
B=
eena could use the Dynamic Client Registration to have all those devices re=
gistered as oAuth Clients. But this seems to be inconvenient as he describe=
s.

In the password grant flow, the device holds th=
e password and is not involved in any interaction with the AS. This keeps t=
he device use case simple.=C2=A0
=C2=A0



Aaron Parecki





On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <beenapurushothaman@gmail.com&=
gt;

wrote:



> Hi,

>

>

> We have a product with client server architecture where our server man=
ages

> thousands of devices. Each device has a client-piece that talks to the=


> server over SOAP/REST. The client currently uses a HTTP Basic

> Authentication (unique id and a secret string) for all the calls. The<=
br>
> secret string is created when the device enrolls to the server. It is<=
br>
> available at the server as well as stored securely on the device. For =
the

> rest calls it is the device that is getting authenticated.

>

>

>

>=C2=A0 Sending the credentials every time is less than ideal and we wan=
t to move

> to some tokenized device authentication. We evaluated OpendID Connect =
based

> on the general recommendation of SSO solution, but the issue is we do =
not

> have any user interaction and hence there is no Grant flow that is fit=
ting.

> Hence we evaluated OAuth grant type of which we found Password Grant a=
nd

> Client Credentials Grant is matching our requirement.

>

>

>

>=C2=A0 In order to use Client Credentials in our use case, we need to d=
o dynamic

> registration for the thousands of devices managed by the server, if Io=
T

> comes into picture the number is going to be even higher, which is hig=
hly

> cumbersome to manage.=C2=A0 Also, as per=C2=A0 RFC7591 on dynamic clie=
nt

> registration, using access token for registering client is optional to=
o.

> Even though the Password grant is highly discouraged by the spec, we f=
ound

> it to be highly matching with our requirements.

>

>

>

> But as per the Oauth 2.1 proposal, password grant is going to be remov=
ed. Can

> you suggest the way forward for us? I believe we are not a one-off cas=
e.

>

>

> Thank You,

>

> Beena

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/887311=
7a/attachment.html>



------------------------------



Subject: Digest Footer



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





------------------------------



End of OAuth Digest, Vol 139, Issue 45

**************************************




-- 
Francis Pouatcha
Co-Founder and Technical Lead=
 at adorys
=


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000097109105a56ae61c--


From nobody Mon May 11 22:40:37 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70793A0C3E for ; Mon, 11 May 2020 22:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37Z3_io_Ecwn for ; Mon, 11 May 2020 22:40:34 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C88F3A0C3C for ; Mon, 11 May 2020 22:40:34 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id z15so229314pjb.0 for ; Mon, 11 May 2020 22:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=VmYvgYJxliyxf1+Wm0HLacK+UvaH2uH+/nUWBGRCSZQ=; b=qLtXRz15xHvrBVC+ib2boCswVNRiSGC7PShLFIyomsn83513FIzZ8B7m77Ba0QjLAG NlgR3FJtjk6aFApzpbP0JRXK7gmQtSjZJ/u71Yht9Zd5832HNoM0WrA5rPQedop5Hhkc +izUdy3pPk1nAzBmRXvCo1Vr6+VTzf3Iz5NMA9j5+pYV4+K3LoekhKjAHVuK9WFVxVnj xhI6aJrzPRSbVDHOfoTXAXRfNUvTTVFGKG2xvlwGAyTaXkctkMxE458w5kxhrA3Z12DE NywckzLy8RToK2Zji2e/y5ef55UJWaLCiFrk+nyBzl02sIbP33joLDbfvPIDWhmIjbDa iYRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=VmYvgYJxliyxf1+Wm0HLacK+UvaH2uH+/nUWBGRCSZQ=; b=Gnm3Gib4Insm7iXygUXHPH5VftEwsSld6z41gCquix8DBOkXmYrxbdUe+TcwXGGMRx KTIjES+0+MnbH4uRUGDoGgv3GqZkvng2LpfdDnU+9HqjxHmpSqILr8KOCQVcmP5+Ze0m oLK5qm+4t3GSXVHEc6mL96gSadtsgf5SoeAjSmqrNp4uQsW61X/YZhnJxsmYvYSfmD6T lgfgzGKn0vEG/J8cf6aZw3YsmwiYtXQHy4RxttNdseKGQPvfRYj2fug8KAl8LvdX81o8 bvQrbCgFxUqYkCnMOPfMZTMBYWv7wEw+puYLU8inTZjiov1LxJfY+8gq5VkgXsB31pxC EJMg==
X-Gm-Message-State: AGi0PuYIBraryeWewzkVgw4cPgdQtBBYqz2Op8MK/dT1PKM2COZjFngT x9JecJqxMfzgXaqSyaAyCXfWZA==
X-Google-Smtp-Source: APiQypLfjCr8/b+ihmJ9M7cyaRFOenPLz95JcCtN1irOYe8fxedYbWTDnCJ3YqKnzZHVt4JsN1k5jA==
X-Received: by 2002:a17:902:8496:: with SMTP id c22mr18711180plo.182.1589262032989;  Mon, 11 May 2020 22:40:32 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id q6sm10722515pfh.193.2020.05.11.22.40.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 22:40:32 -0700 (PDT)
From: Vittorio Bertocci 
To: Jared Jennings 
CC: Denis , Benjamin Kaduk , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AXdwTzB4ofd1XzKTR3gsOll1nC4/fDAxQjMxu+3udACAACjKQw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 12 May 2020 05:40:30 +0000
Message-ID: 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB15018666981170A2DAA7B0D7AEBE0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 05:40:36 -0000

--_000_MWHPR19MB15018666981170A2DAA7B0D7AEBE0MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

It=92s not really an interop issue either, given that following or not foll=
owing this requirement doesn=92t alter the shape of messages or tokens. It=
=92s more of an architectural requirement, which preserves the relationship=
s between the OAuth2 roles involved and prevents the confusion that might a=
rise by the availability of data that characterizes this particular scenari=
o, but that doesn=92t change the more general premises of the protocol. In =
terms of finding common ground, I am not sure if visions as diametrically o=
pposed as pitting a MUST against a MUST NOT have much of an achievable comm=
on ground, especially given that the MUST NOT stance already passed consens=
us in the past year, and in more than one month of very public debate durin=
g last calls, the MUST side had mostly one backer and more than one opposed=
.

From: Jared Jennings 
Date: Monday, May 11, 2020 at 20:14
To: Vittorio Bertocci 
Cc: Denis , Benjamin Kaduk , "oauth@ietf=
.org" 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide implementors =
from making bad choices, not from a security perspective. Meaning, it's not=
 a security risk that a client does inspect or analyze the token. Instead, =
it's is an interop issue and thus we are guiding implementors to never assu=
me or expect the token format to be consistent or of a expected format, for=
 various reasons. I kinda know the answer to this question, but I am kinda =
asking this way to help restate the intent of the "topic" and maybe help gu=
ide to a wording that works for everyone.

For example, as a consultant, it can be very helpful to know how to decompi=
le or inspect an "Object", but at the same time knowing that such a method =
or practice should never be used in production.

Jared



On May 11, 2020, at 19:24, Vittorio Bertocci > wrote:

Real world scenarios are full of situations where additional assumptions ca=
n lower dangers that must be taken in consideration in the general case, wh=
ich might make less of a risk going against the specin those particular cir=
cumstances, but their existence doesn=92t warrant relaxing guidance for the=
 general case. A concrete example: I worked on scenarios where resource ser=
vers wanted to guarantee some degree of business continuity in case of AS o=
utage, which boiled down to RS=92 willingness to accept ATs past their decl=
ared expiration time, on the condition that the AS outage condition was det=
ectable and the staleness of the AT didn=92t cross a tolerance threshold. T=
he business scenario made sense, and the implementer was within their right=
 in deciding that disregarding exp in those circumstances was acceptable. N=
onetheless, I would not argue that given the existence of that scenario, rf=
c7519 should turn its MUST NOT into a SHOULD NOT.



--_000_MWHPR19MB15018666981170A2DAA7B0D7AEBE0MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











It=92s not really an interop issue either, given tha=
t following or not following this requirement doesn=92t alter the shape of =
messages or tokens. It=92s more of an architectural requirement, which pres=
erves the relationships between the OAuth2
 roles involved and prevents the confusion that might arise by the availabi=
lity of data that characterizes this particular scenario, but that doesn=92=
t change the more general premises of the protocol. In terms of finding com=
mon ground, I am not sure if visions
 as diametrically opposed as pitting a MUST against a MUST NOT have much of=
 an achievable common ground, especially given that the MUST NOT stance alr=
eady passed consensus in the past year, and in more than one month of very =
public debate during last calls,
 the MUST side had mostly one backer and more than one opposed.   =
;


 




From=
: Jared Jennings &l=
t;jaredljennings@gmail.com>

Date: Monday, May 11, 2020 at 20:14

To: Vittorio Bertocci <vittorio.bertocci@auth0.com>

Cc: Denis <denis.ietf@free.fr>, Benjamin Kaduk <kaduk@mit.e=
du>, "oauth@ietf.org" <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






 




Hi Vittorio, 




 






Yeah, this does make a bit of sense. So, the goal is=
 to guide implementors from making bad choices, not from a security perspec=
tive. Meaning, it's not a security risk that a client does inspect or analy=
ze the token. Instead, it's is an
 interop issue and thus we are guiding implementors to never assume or expe=
ct the token format to be consistent or of a expected format, for various r=
easons. I kinda know the answer to this question, but I am kinda asking thi=
s way to help restate the intent
 of the "topic" and maybe help guide to a wording that works for =
everyone.






 






For example, as a consultant, it can be very helpful=
 to know how to decompile or inspect an "Object", but at the same=
 time knowing that such a method or practice should never be used in produc=
tion.






 






Jared






 















On May 11, 2020, at 19:24, Vittorio Bertocci <vittorio.bertocci@auth0.com=
> wrote:




 






Real world scenarios are full of situations where ad=
ditional assumptions can lower dangers that must be taken in consideration =
in the general case, which might make less of a risk going against the spec=
in those particular circumstances,
 but their existence doesn=92t warrant relaxing guidance for the general ca=
se. A concrete example: I worked on scenarios where resource servers wanted=
 to guarantee some degree of business continuity in case of AS outage, whic=
h boiled down to RS=92 willingness to
 accept ATs past their declared expiration time, on the condition that the =
AS outage condition was detectable and the staleness of the AT didn=92t cro=
ss a tolerance threshold. The business scenario made sense, and the impleme=
nter was within their right in deciding
 that disregarding exp in those circumstances was acceptable. Nonetheless, =
I would not argue that given the existence of that scenario, rfc7519 should=
 turn its MUST NOT into a SHOULD NOT.




 








 








--_000_MWHPR19MB15018666981170A2DAA7B0D7AEBE0MWHPR19MB1501namp_--


From nobody Mon May 11 23:27:14 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6494A3A0C68 for ; Mon, 11 May 2020 23:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8zsAhTByds9 for ; Mon, 11 May 2020 23:27:11 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E53A3A0C67 for ; Mon, 11 May 2020 23:27:11 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id s8so13835045wrt.9 for ; Mon, 11 May 2020 23:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cmQirh+ECJNC0Op72oi2p4jLnHTZ6I9oozbq5XIxp40=; b=R82Yftwvpjt8LVOCiT+wVz3Z89mmDQItZTat9K5JsaKKz/+TfKxTHV0AVUapEhdAye IlJvT+d2Hzg93ngFlU4iSytFg2HXNiNJB+2eS42I8vZkwrr2cg0FaTsHXwHCxR37kG+W SZZPE2shMptlVLXN9WhC2qctMT4vD39fm63V+pn8IR98lxhi/a3eQ43cZpHVSEdCW7xy ACcRtXHQUHiGVXxvWIHSYcizqQQtTBk4iqGApTQH5P0qnbL70OtT+hvTwyVU3l8hj3vz GtFFbSfNwAlT5m4S3AAdJpSbJn0PPE1B8lGbEHY749+wGr0xybOKydQR2Uo7mcqY1pxj hCLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cmQirh+ECJNC0Op72oi2p4jLnHTZ6I9oozbq5XIxp40=; b=nY8VkcAQkGREnBpjwQUITYEf0vSTwq6oVrYRJQYqcHlFoGIAIibet3Qh4MbppM2XPM d5YI3HVVbTTMmwsBaSzewG626vk/mZ45wJOm1TqzueMsm0KmCOon0zIsf4+gC6CyGAm5 i6X71+lXtZ1adtI+vpukIfExm6uXBfJ55Xebp3tLXWq9E4+EG5ulNwpziHb+W/wD6A9M DCMNvWM8EEUmlL+UKEGDw3kAyC+dZle0ISyfAjPPvv2qrWtcbJl43O42pQB78WAZv9Iz aQzkCR0U+NKNK7AHsuPwC+pTOVMsVZDVeBj8byUNaONDtfuA4P3ENj14vCM7tc0pstyS Hrmw==
X-Gm-Message-State: AGi0PuYfLvbqnLkxUFlhCp+IpNxqPTAvc8oBHkJ8O1AcuwaAXUUJckGo ZhTlC6ZDvZGSsnsbTmNiOV4LgKkJA6k=
X-Google-Smtp-Source: APiQypLBUmviwdz9CO3cJpf/fP1ologIcs7yQ2cLjHrs0+vdhtIG1kVNndZsIWz6ANjRHvFWORLCHA==
X-Received: by 2002:adf:e4d0:: with SMTP id v16mr23132425wrm.294.1589264829313;  Mon, 11 May 2020 23:27:09 -0700 (PDT)
Received: from p200300eb8f301f8a19b19ebeb365836a.dip0.t-ipconnect.de (p200300EB8F301F8A19B19EBEB365836A.dip0.t-ipconnect.de. [2003:eb:8f30:1f8a:19b1:9ebe:b365:836a]) by smtp.gmail.com with ESMTPSA id c19sm22096147wrb.89.2020.05.11.23.27.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 23:27:08 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Tue, 12 May 2020 08:27:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: oauth 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 06:27:13 -0000

Hi all,

I initially raised the question whether the AS should be able to require =
request objects for all clients (in the same way as we decided to let =
the AS required PAR for all clients) but this topic was never discussed =
later on.=20

I suggest to add a server metadata parameter =
=E2=80=9Crequire_request_objects=E2=80=9D so the AS can indicate its =
policy to clients.=20

I think the best place to define this parameter would be JAR, if that is =
not possible any longer, we could use a different PAR-specific name and =
add it to PAR.

What do you think?

best regards,
Torsten.=20

> On 1. May 2020, at 17:56, Mike Jones =
 wrote:
>=20
> Works for me.
>=20
> =20
>=20
> From: OAuth  On Behalf Of Torsten Lodderstedt
> Sent: Friday, May 1, 2020 2:51 AM
> To: Brian Campbell 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
>=20
> =20
>=20
> Filip=C2=B4s proposal works for me.
>=20
> =20
>=20
> Are there any objections?
>=20
> =20
>=20
> Brian Campbell  schrieb =
am Mo. 27. Apr. 2020 um 20:57:
>=20
> While there are certainly different permutations and contexts of use =
that could be imagine, I tend to agree with Filip here in not seeing a =
strong need to define new PAR specific metadata around =
signing/encryption of the request object.
>=20
> =20
>=20
> On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  =
wrote:
>=20
> Considering there's going to be a setting that forces clients to use =
PAR (other mailinglist thread), then we should rely on the existing =
`request_object_signing_alg` presence to indicate a Request Object must =
be used (as suggested by this upcoming OIDC Core errata), regardless of =
it being PAR or JAR. I don't see the need for a PAR specific metadata, =
for one - implementations wouldn't be easily able to re-use of existing =
pipelines, two - yes the contexts differ but do you think clients will =
be using both channels at the same time? And even if so, the Request =
Object is the same therefore its applicable to both channels the same.
>=20
>=20
> Best,
> Filip Skokan
>=20
> =20
>=20
> =20
>=20
> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt =
 wrote:
>=20
> Hi all,=20
>=20
> this is one of the topics we quickly flipped through in the virtual =
meeting last week.=20
>=20
> I see the following open questions:
> - Can the client require its instances to use request objects only.
> - Are there further requirements on the properties of these objects? =
Signed only, Signed and encrypted, algorithms?=20
> - Can an AS require ALL clients to use request objects only?=20
> - Further requirements here as well?=20
> - Is this tied to PAR or relevant for JAR as well?=20
>=20
> In my opinion, client as well as AS should be able to control enforced =
use of request objects.=20
>=20
> I could imagine the setting for JAR request objects (=E2=80=9Crequest" =
parameter) and request objects in the PAR context differ, as the first =
case goes through the user=E2=80=99s browser whereas the PAR case goes =
direct from client to AS via a TLS protected channel. I therefore feel =
the settings should be PAR specific.=20
>=20
> What do you think?
>=20
> best regards,
> Torsten.=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
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited...  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank you.
>=20


From nobody Tue May 12 00:01:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8463A0819 for ; Tue, 12 May 2020 00:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udpQcyZ9HPSo for ; Tue, 12 May 2020 00:01:48 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5973A0885 for ; Tue, 12 May 2020 00:01:47 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id q206so6461476ybg.1 for ; Tue, 12 May 2020 00:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5uk1xthSbqYc5MNJxk0xqkjnEd+zAjxGQb0uZLGXRCw=; b=tT5zI30SGYiZhHkyi6lyQ9OKRYVqskDRwJzXnKjNG+k1Ksqcp64UMbUyz3K0Wu7zON D+WEiLKZ2np5OF3THG1L1vpErG5tqfqPFAk7su1ES40Kjf/uJgiqQ/xNxjViVh9yhJ9J hI0oiNnBTRyyjBHBCsv9Uj3rwah3dLABVxDTy9cX7t1RvobE0KRsJ/6pZV9YV3XkHuzd 7Q1SsjB6z9wyL8/d0n35c6MruRB9/CF8EB7pufhJwDW0RVTntDQP2uTH73HRxM0AM/xz 1WnyZXuRQs276roMCAtOYILbBBzYUV5snyemsSZDALQo25UbO0ITWbLGw02xZ2u+UU1n u6cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5uk1xthSbqYc5MNJxk0xqkjnEd+zAjxGQb0uZLGXRCw=; b=JwX3o7npwNUHPD32uxIw//Ek38iqhAEHaYtM6QHEkp5zmzoLNgoz5yAzv9TYsdY/nj hnu1RxDBx/5L1kJl7rER1ljbqerl36XVDYhtoTY+2l2zgefoOjI4nssVTJKPRvOXCSb0 +EXh0fw/vBNWHLXyzb9/6ig1BYAWy/OZLvKa/+SkecW5eCAqjHT8UU90jnXYWeqD6x8Z 0t8C5EoVhM4wBDHmZcz8tAWbIYdIPYkM5jWXT/K3qKYZQbJksnprOyqcWtRH6b4PUPq/ C4GV5g2uBmklgvMQQEjXvOcsxWeCkeIbquLtZO0B+fu3Z+C2OxT9jbO/CI8C74WYWsOU uyDw==
X-Gm-Message-State: AGi0PubXZ5MxOH2KoKW3yd6MENYXlylLsdNIfuTA8iEYlHV1JisrOy2O KD2ziyj92patpB1SghGkiWGxj3FJzLy3T471qQ==
X-Google-Smtp-Source: APiQypK9UwvKUoRQEx7Xuxz1foCccTYWjX/U2As5BokKEbmSPEHdzeD7/6vuClAQ4pFqHh3jegD8qhUzwrx2BNchQ8Q=
X-Received: by 2002:a5b:44b:: with SMTP id s11mr31695234ybp.399.1589266906029;  Tue, 12 May 2020 00:01:46 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Filip Skokan 
Date: Tue, 12 May 2020 09:01:10 +0200
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000006321cc05a56e0965"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 07:01:52 -0000

--0000000000006321cc05a56e0965
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think require_request_objects has its place, that place should be JAR,
PAR as a backup. I believe doing only the "PAR-specific" name / meaning of
it would be a missed opportunity.

S pozdravem,
*Filip Skokan*


On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt  wrote:

> Hi all,
>
> I initially raised the question whether the AS should be able to require
> request objects for all clients (in the same way as we decided to let the
> AS required PAR for all clients) but this topic was never discussed later
> on.
>
> I suggest to add a server metadata parameter =E2=80=9Crequire_request_obj=
ects=E2=80=9D so
> the AS can indicate its policy to clients.
>
> I think the best place to define this parameter would be JAR, if that is
> not possible any longer, we could use a different PAR-specific name and a=
dd
> it to PAR.
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 1. May 2020, at 17:56, Mike Jones  40microsoft.com@dmarc.ietf.org> wrote:
> >
> > Works for me.
> >
> >
> >
> > From: OAuth  On Behalf Of Torsten Lodderstedt
> > Sent: Friday, May 1, 2020 2:51 AM
> > To: Brian Campbell 
> > Cc: oauth 
> > Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
> >
> >
> >
> > Filip=C2=B4s proposal works for me.
> >
> >
> >
> > Are there any objections?
> >
> >
> >
> > Brian Campbell  schrieb =
am
> Mo. 27. Apr. 2020 um 20:57:
> >
> > While there are certainly different permutations and contexts of use
> that could be imagine, I tend to agree with Filip here in not seeing a
> strong need to define new PAR specific metadata around signing/encryption
> of the request object.
> >
> >
> >
> > On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  wrote=
:
> >
> > Considering there's going to be a setting that forces clients to use PA=
R
> (other mailinglist thread), then we should rely on the existing
> `request_object_signing_alg` presence to indicate a Request Object must b=
e
> used (as suggested by this upcoming OIDC Core errata), regardless of it
> being PAR or JAR. I don't see the need for a PAR specific metadata, for o=
ne
> - implementations wouldn't be easily able to re-use of existing pipelines=
,
> two - yes the contexts differ but do you think clients will be using both
> channels at the same time? And even if so, the Request Object is the same
> therefore its applicable to both channels the same.
> >
> >
> > Best,
> > Filip Skokan
> >
> >
> >
> >
> >
> > On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
> >
> > Hi all,
> >
> > this is one of the topics we quickly flipped through in the virtual
> meeting last week.
> >
> > I see the following open questions:
> > - Can the client require its instances to use request objects only.
> > - Are there further requirements on the properties of these objects?
> Signed only, Signed and encrypted, algorithms?
> > - Can an AS require ALL clients to use request objects only?
> > - Further requirements here as well?
> > - Is this tied to PAR or relevant for JAR as well?
> >
> > In my opinion, client as well as AS should be able to control enforced
> use of request objects.
> >
> > I could imagine the setting for JAR request objects (=E2=80=9Crequest"
> parameter) and request objects in the PAR context differ, as the first ca=
se
> goes through the user=E2=80=99s browser whereas the PAR case goes direct =
from
> client to AS via a TLS protected channel. I therefore feel the settings
> should be PAR specific.
> >
> > What do you think?
> >
> > best regards,
> > Torsten.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited...  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any fi=
le
> attachments from your computer. Thank you.
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000006321cc05a56e0965
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think=C2=A0require_request_objects has its place, that p=
lace should be JAR, PAR as a backup. I believe doing only the "PAR-spe=
cific" name / meaning of it would be a missed opportunity.

S pozdravem,
Filip Skokan


On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.o=
rg> wrote:
40microsoft.com@dmar=
c.ietf.org> wrote:

> 

> Works for me.

> 

>=C2=A0 

> 

> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt

> Sent: Friday, May 1, 2020 2:51 AM

> To: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g=
t;

> Cc: oauth <oaut=
h@ietf.org>

> Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
> 

>=C2=A0 

> 

> Filip=C2=B4s proposal works for me.

> 

>=C2=A0 

> 

> Are there any objections?

> 

>=C2=A0 

> 

> Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> s=
chrieb am Mo. 27. Apr. 2020 um 20:57:

> 

> While there are certainly different permutations and contexts of use t=
hat could be imagine, I tend to agree with Filip here in not seeing a stron=
g need to define new PAR specific metadata around signing/encryption of the=
 request object.

> 

>=C2=A0 

> 

> On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan <panva.ip@gmail.com> wrote:

> 

> Considering there's going to be a setting that forces clients to u=
se PAR (other mailinglist thread), then we should rely on the existing `req=
uest_object_signing_alg` presence to indicate a Request Object must be used=
 (as suggested by this upcoming OIDC Core errata), regardless of it being P=
AR or JAR. I don't see the need for a PAR specific metadata, for one - =
implementations wouldn't be easily able to re-use of existing pipelines=
, two - yes the contexts differ but do you think clients will be using both=
 channels at the same time? And even if so, the Request Object is the same =
therefore its applicable to both channels the same.

> 

> 

> Best,

> Filip Skokan

> 

>=C2=A0 

> 

>=C2=A0 

> 

> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt <torsten=3D40lodderste=
dt.net@dmarc.ietf.org> wrote:

> 

> Hi all, 

> 

> this is one of the topics we quickly flipped through in the virtual me=
eting last week. 

> 

> I see the following open questions:

> - Can the client require its instances to use request objects only.
> - Are there further requirements on the properties of these objects? S=
igned only, Signed and encrypted, algorithms? 

> - Can an AS require ALL clients to use request objects only? 

> - Further requirements here as well? 

> - Is this tied to PAR or relevant for JAR as well? 

> 

> In my opinion, client as well as AS should be able to control enforced=
 use of request objects. 

> 

> I could imagine the setting for JAR request objects (=E2=80=9Crequest&=
quot; parameter) and request objects in the PAR context differ, as the firs=
t case goes through the user=E2=80=99s browser whereas the PAR case goes di=
rect from client to AS via a TLS protected channel. I therefore feel the se=
ttings should be PAR specific. 

> 

> What do you think?

> 

> best regards,

> Torsten. 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> 

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

> 



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000006321cc05a56e0965--


From nobody Tue May 12 00:10:26 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97B53A0887 for ; Tue, 12 May 2020 00:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpfWulX-NSij for ; Tue, 12 May 2020 00:10:22 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF67D3A0885 for ; Tue, 12 May 2020 00:10:22 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id v4so9302943qte.3 for ; Tue, 12 May 2020 00:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=WXwZGMPT2bOpvnzxVYt+O82FHrgOzbzJfDY4qZB5QYE=; b=mv8dagMq3US90XHCiouMvH8LWFPfI0vCXc4g3wu/EkDl3gj3F+rvuhaJmi75QlUsFl PNtDa1y6J6D/xb6FzsOa2hkmdRoyxCVlj376qr4YpSPRI3ckbhkuyax84wlhyZHZ/mUu iYXUNl9UBR83I1WN04IspW2zS/ysZWSrnsJTbkdQRzdN6V1fxizvfnRXQkjmexNfXG54 iSJDzgtn6d069KbHt+IJPeiQPOYAyIFue1J+Y340G0dSkZugcx+sT+TkZTJkC0sC6hZI qf1pyCkTXWHNeuZsdU1txxCCbNvwf2L41LjCMKEFDLk0c6zs5KA/6+ugOubKeh/AApHQ Pk6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WXwZGMPT2bOpvnzxVYt+O82FHrgOzbzJfDY4qZB5QYE=; b=i150e179dInFn3ToqDK3FRwh2xEyPJXjQOFz8Q3BjiMG2gqJu2c42IHtGLPOyeftHR Vl/i/qJQ15bOveebyku18L+LhxDTLDbeTJiziyhaPP9Y9l4s9suAOaDx0YU960lOxco8 oxLepGjk5UJ5a+sFarTd5PcivfuVgflU72O8DxQejXk2+nGHLhebgVUnUUKGHtoVC0aD HP9bi0F+iXj/jRHOF3GagQNyxnOwQmz5eHeE0K1riofanjc5fq3EmtyDbG1XT2K7SbE8 1AqIR3arYuNFY2RCyRumPPdzCVARa1z5NQU0JALWmOjLbQHd846JIz/r8vpvpbM63b/0 H/gg==
X-Gm-Message-State: AGi0PuY4HobZ6mIPML3wFyimwwdQz+zlNeuc1smnXQw75OF3H09v0SOV 6IwmaHEeRvVf/QNwzwYctw8gskhhQGPHCp7FNYcmXRAZIjU=
X-Google-Smtp-Source: APiQypJ0DA9a/Ot14eGqpjoOgH71VKCpdoldSEOGZTQvaJoasD4BCgPeV348r9xaXL3XMP15zaL2g8RlaS+PTKVK6Jk=
X-Received: by 2002:ac8:7758:: with SMTP id g24mr19338102qtu.85.1589267421504;  Tue, 12 May 2020 00:10:21 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Beena Santhosh 
Date: Tue, 12 May 2020 12:40:10 +0530
Message-ID: 
To: Aaron Parecki , oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001cb08205a56e28c8"
Archived-At: 
Subject: Re: [OAUTH-WG] Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 07:10:25 -0000

--0000000000001cb08205a56e28c8
Content-Type: text/plain; charset="UTF-8"

Hi Aaron,


What we are planning to build is a Public first party client. As per the
spec the client secret is optional for Password Grant. Hence we choose to
use a common client_id across all the devices. The first party client on
every device  will get the  common client_id through our proprietary API.
We found this as a difference between Password Grant and Client credentials
grant. We could be wrong but this is our interpretation.  This way we could
make use of the rest of the benefits that OAuth provides around access
tokens


Thank You,

Beena

On Mon, May 11, 2020 at 11:15 PM Aaron Parecki  wrote:

> With the password grant you'd then need to register 50,000+ user accounts,
> right? How is that different from registering that many clients?
>
> On Mon, May 11, 2020 at 10:39 AM Beena Santhosh <
> beenapurushothaman@gmail.com> wrote:
>
>> Hi Aaron,
>>
>> Thank You for the quick response.
>>
>> We do support  1, 50, 000+ devices and that means we need to register
>> those many devices dynamically,  the provider we have evaluated  is not
>> supporting that scale . Once we  incorporate IoT, we need to support
>> millions of devices. With Password Grant as we need only one client_id it
>> is easy to manage. Also our client is First Party client.
>>
>>
>> Thank You,
>>
>> Beena
>>
>> On Sun, May 10, 2020 at 7:50 PM Aaron Parecki  wrote:
>>
>>> Hi Beena,
>>>
>>> This sounds like a great use of the client credentials grant. The
>>> password grant is being removed from OAuth 2.0 by the Security Best Current
>>> Practice. Can you clarify what you've found useful about the password grant
>>> that the client credentials grant doesn't solve?
>>>
>>> Aaron Parecki
>>>
>>>
>>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>>> beenapurushothaman@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> We have a product with client server architecture where our server
>>>> manages thousands of devices. Each device has a client-piece that talks to
>>>> the server over SOAP/REST. The client currently uses a HTTP Basic
>>>> Authentication (unique id and a secret string) for all the calls. The
>>>> secret string is created when the device enrolls to the server. It is
>>>> available at the server as well as stored securely on the device. For the
>>>> rest calls it is the device that is getting authenticated.
>>>>
>>>>
>>>>
>>>>  Sending the credentials every time is less than ideal and we want to
>>>> move to some tokenized device authentication. We evaluated OpendID Connect
>>>> based on the general recommendation of SSO solution, but the issue is we do
>>>> not have any user interaction and hence there is no Grant flow that is
>>>> fitting. Hence we evaluated OAuth grant type of which we found Password
>>>> Grant and Client Credentials Grant is matching our requirement.
>>>>
>>>>
>>>>
>>>>  In order to use Client Credentials in our use case, we need to do
>>>> dynamic registration for the thousands of devices managed by the server, if
>>>> IoT comes into picture the number is going to be even higher, which is
>>>> highly cumbersome to manage.  Also, as per  RFC7591 on dynamic client
>>>> registration, using access token for registering client is optional too.
>>>> Even though the Password grant is highly discouraged by the spec, we found
>>>> it to be highly matching with our requirements.
>>>>
>>>>
>>>>
>>>> But as per the Oauth 2.1 proposal, password grant is going to be removed.
>>>> Can you suggest the way forward for us? I believe we are not a one-off
>>>> case.
>>>>
>>>>
>>>> Thank You,
>>>>
>>>> Beena
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>

--0000000000001cb08205a56e28c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Aaron,

=

What we are planning to build is a Public first party =
client.
As per the spec the client secret is=C2=A0optional for Password Grant. Hence we choose to use a common
client_id across all the devices. The first party client on every device=C2=
=A0 will get
the=C2=A0 common client_id through our
proprietary API. We found this as a difference between Password Grant and
Client credentials grant. We could be wrong but this is our
interpretation.=C2=A0 This way we could make
use of the rest of the benefits that =
OAuth provides around access tokens=C2=A0

Thank You,=C2=A0
Beena=


On Mon, May 11, 2020 at 11:15 PM Aaron Parecki <aaron@parecki.com> wrote:
With the p=
assword grant you'd then need to register 50,000+ user accounts, right?=
 How is that different from registering that many clients?=C2=A0

<=
div class=3D"gmail_quote">
On Mon, May=
 11, 2020 at 10:39 AM Beena Santhosh <beenapurushothaman@gmail.com> wrote:=

Hi Aaron,

Thank You for the quick=C2=A0response.
=


We do support=C2=A0 1, 50, 000+ devices and that means we need to
register those many devices dynamically,=C2=A0
the provider we have evaluated=C2=A0 is
not supporting that scale . Once we=C2=A0
incorporate IoT, we need to support millions of devices. With Password
Grant as we need only one client_id it is easy to manage. Also our client i=
s
First Party client.=C2=A0

Thank You,
Beena

On Sun, May 10, 2020 at 7:50 PM Aaron Parecki <aaron@parecki.com> w=
rote:
Hi Beena,

This sounds like a great use of the c=
lient credentials grant. The password grant is being removed from OAuth 2.0=
 by the Security Best Current Practice. Can you clarify what=C2=A0you'v=
e found useful about the password grant that the client credentials grant d=
oesn't solve?=C2=A0

Aaron Parecki

On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <beenapurushothaman@gmail.=
com> wrote:
Hi,

<=
/p>
We have a pro=
duct
with client server architecture where our server manages thousands of devic=
es.
Each device has a client-piece that talks to the server over SOAP/REST. The
client currently uses a HTTP Basic Authentication (unique id and a secret
string) for all the calls. The secret string is created when the device enr=
olls
to the server. It is available at the server as well as stored securely on =
the
device. For the rest calls it is the device that is getting authenticated.<=
/p>


=C2=A0



=C2=A0Sending th=
e credentials every time is less
than ideal and we want to move to some tokenized device authentication. We
evaluated OpendID Connect based on the general recommendation of SSO soluti=
on,
but the issue is we do not have any user interaction and hence there is no
Grant flow that is fitting. Hence we evaluated OAuth grant type of which we
found Password Grant and Client Credentials Grant is matching our requireme=
nt.



=C2=A0



=C2=A0In order t=
o use Client Credentials in our use
case, we need to do dynamic registration for the thousands of devices manag=
ed
by the server, if IoT comes into picture the number is going to be even hig=
her,
which is highly cumbersome to manage.=C2=A0
Also, as per=C2=A0 RFC7591 on dynamic
client registration, using access token for registering client is optional
too.=C2=A0 Even though the Password grant is
highly discouraged by the spec, we found it to be highly matching with our
requirements.



=C2=A0



=
But as
per the Oauth 2.1 proposal, password grant is going to be removed. Can
you suggest the way forward for us? I
believe we are not a one-off case.

Thank You,<=
/span>
Beena

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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










--0000000000001cb08205a56e28c8--


From nobody Tue May 12 00:28:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F4D3A0C98 for ; Tue, 12 May 2020 00:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39ZsPJj7Pr-9 for ; Tue, 12 May 2020 00:28:07 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7337C3A083C for ; Tue, 12 May 2020 00:28:07 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id y16so6836695wrs.3 for ; Tue, 12 May 2020 00:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3pmfZFRrha1LCNESYoWcWTBPFnxYfbvySo1wMQw52DA=; b=IT/csqdllg/kqFXbGORiwfAqG3c3b5je/3r9sdkzbXS9wo+kbWEpdOQhzh5IZbMV1B R/eleeNjWu/2OtiQDKaachsmTJgW2+nJI5uGZI9LIrxSYVChSJT7x8wVAJOiku/xFOro IcGySA3ld/3TBb5fOZ1MI+j5mGttXxfBDxlExhPgUwe3L+1aLGMOP0M0liF2RnRjLAm0 Vs2EVRMZCNKfGgCrGjh4qDcN5E21jM4t6+YvUz4OHmXS/TCpB2erTU+DEBH8TUCGoYDk OHRfFjGUIagtsS/IGde5yls/vVk7IdThCig/h+PJvg+ChnEPyDt+mBJrDbJ068f2FmhD p1gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3pmfZFRrha1LCNESYoWcWTBPFnxYfbvySo1wMQw52DA=; b=gDZdSseGAFDYVMzy056rj9+WITX8TbJm8chNY1Rzt9/sxQpfn6Z3/9KrPhXm3HUaAq MqY13mBAMcscx0d1v06pi65y1eDaiscbrfbulBP+lalkUB83n++u4qFYJT604Yr4nUY5 BeUJJVk5/3Z4HNGY4fxZtgS+5Gus05OajrVt0rfFbA01XteaEp8N77HmbTu9cE71mu2b 6UiZKh/qwQf7do94vcA7xrcJl1nqG/b3W9JK3mg/B5hm5GsEUK1BPBMWiQDVzi6Yf8qm mshRHt4dlq2iLDAtJqbPNVhMPiJpN0Qj1URUXlqDPTejY8swoY744L/NOx5XmsWqUUaO V3qg==
X-Gm-Message-State: AOAM5316MhLj+dSOT/AAxyQDRxDbcz0G7O1T8Xaw6hIUv4vhjLONIAtO rGnDKOnzOg65KEGZe9hXMkct4m1W5mAWYbsenn0=
X-Google-Smtp-Source: ABdhPJwY5r9L8A2e+HbQGN4M9Qrt8jMPRoDavokzll5q2Bfv1L0l/8XK/tIdmA/5AECwlpsTEC25eAeftzOdkBFMclc=
X-Received: by 2002:a05:6000:ce:: with SMTP id q14mr1065244wrx.105.1589268485679;  Tue, 12 May 2020 00:28:05 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Thibault Normand 
Date: Tue, 12 May 2020 09:27:54 +0200
Message-ID: 
To: Filip Skokan 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="0000000000008aaf6b05a56e67e6"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 07:28:10 -0000

--0000000000008aaf6b05a56e67e6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

I'm currently implementing a new OIDC server (
https://github.com/Zenithar/go-solid) with restricted features such as PAR,
enforce PKCE, etc.
For other clients, that don't have the support of PAR it would be great to
be able to detect that PAR is enforced by default.

Also, I have a question about using JWT for initial request registration,
I'm enforcing default asymmetric authentication (private_key_jwt, and mTLS
(not implemented yet) with restricted encryption algorithms, if I use the
private key of the client to sign the JWT request registration, and use
client_assertion, it sounds for me like using the same key for multiple
purposes.

Regards,

Le mar. 12 mai 2020 =C3=A0 09:02, Filip Skokan  a =C3=
=A9crit :

> I think require_request_objects has its place, that place should be JAR,
> PAR as a backup. I believe doing only the "PAR-specific" name / meaning o=
f
> it would be a missed opportunity.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> I initially raised the question whether the AS should be able to require
>> request objects for all clients (in the same way as we decided to let th=
e
>> AS required PAR for all clients) but this topic was never discussed late=
r
>> on.
>>
>> I suggest to add a server metadata parameter =E2=80=9Crequire_request_ob=
jects=E2=80=9D so
>> the AS can indicate its policy to clients.
>>
>> I think the best place to define this parameter would be JAR, if that is
>> not possible any longer, we could use a different PAR-specific name and =
add
>> it to PAR.
>>
>> What do you think?
>>
>> best regards,
>> Torsten.
>>
>> > On 1. May 2020, at 17:56, Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote:
>> >
>> > Works for me.
>> >
>> >
>> >
>> > From: OAuth  On Behalf Of Torsten Lodderstedt
>> > Sent: Friday, May 1, 2020 2:51 AM
>> > To: Brian Campbell 
>> > Cc: oauth 
>> > Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
>> >
>> >
>> >
>> > Filip=C2=B4s proposal works for me.
>> >
>> >
>> >
>> > Are there any objections?
>> >
>> >
>> >
>> > Brian Campbell  schrieb
>> am Mo. 27. Apr. 2020 um 20:57:
>> >
>> > While there are certainly different permutations and contexts of use
>> that could be imagine, I tend to agree with Filip here in not seeing a
>> strong need to define new PAR specific metadata around signing/encryptio=
n
>> of the request object.
>> >
>> >
>> >
>> > On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan 
>> wrote:
>> >
>> > Considering there's going to be a setting that forces clients to use
>> PAR (other mailinglist thread), then we should rely on the existing
>> `request_object_signing_alg` presence to indicate a Request Object must =
be
>> used (as suggested by this upcoming OIDC Core errata), regardless of it
>> being PAR or JAR. I don't see the need for a PAR specific metadata, for =
one
>> - implementations wouldn't be easily able to re-use of existing pipeline=
s,
>> two - yes the contexts differ but do you think clients will be using bot=
h
>> channels at the same time? And even if so, the Request Object is the sam=
e
>> therefore its applicable to both channels the same.
>> >
>> >
>> > Best,
>> > Filip Skokan
>> >
>> >
>> >
>> >
>> >
>> > On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt > 40lodderstedt.net@dmarc.ietf.org> wrote:
>> >
>> > Hi all,
>> >
>> > this is one of the topics we quickly flipped through in the virtual
>> meeting last week.
>> >
>> > I see the following open questions:
>> > - Can the client require its instances to use request objects only.
>> > - Are there further requirements on the properties of these objects?
>> Signed only, Signed and encrypted, algorithms?
>> > - Can an AS require ALL clients to use request objects only?
>> > - Further requirements here as well?
>> > - Is this tied to PAR or relevant for JAR as well?
>> >
>> > In my opinion, client as well as AS should be able to control enforced
>> use of request objects.
>> >
>> > I could imagine the setting for JAR request objects (=E2=80=9Crequest"
>> parameter) and request objects in the PAR context differ, as the first c=
ase
>> goes through the user=E2=80=99s browser whereas the PAR case goes direct=
 from
>> client to AS via a TLS protected channel. I therefore feel the settings
>> should be PAR specific.
>> >
>> > What do you think?
>> >
>> > best regards,
>> > Torsten.
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited...  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and any f=
ile
>> attachments from your computer. Thank you.
>> >
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--=20
Thibault Normand
"Il existe moins bien mais c'est plus cher !"
http://www.zenithar.org

--0000000000008aaf6b05a56e67e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I'm currently imp=
lementing a new OIDC server (https://github.com/Zenithar/go-solid) with restricted features such =
as PAR, enforce PKCE, etc.
For other clients, that don't have=
 the support of PAR it would be great to be able to detect that PAR is enfo=
rced by default.

Also, I have a question about usi=
ng JWT for initial request registration, I'm enforcing default asymmetr=
ic authentication (private_key_jwt, and mTLS (not implemented yet) with res=
tricted encryption algorithms, if I use the private key of the client to si=
gn the JWT request registration, and use client_assertion, it sounds for me=
 like using the same key for multiple purposes. 

Regards,

Le=C2=A0mar. 12 mai 2020 =C3=A0=C2=A009:02, Filip Skok=
an <panva.ip@gmail.com> a =
=C3=A9crit=C2=A0:
I think=C2=A0require_request_objects has its place, that=
 place should be JAR, PAR as a backup. I believe doing only the "PAR-s=
pecific" name / meaning of it would be a missed opportunity.

S pozdravem,
Filip Skokan


On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt <tors=
ten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi all,



I initially raised the question whether the AS should be able to require re=
quest objects for all clients (in the same way as we decided to let the AS =
required PAR for all clients) but this topic was never discussed later on. =




I suggest to add a server metadata parameter =E2=80=9Crequire_request_objec=
ts=E2=80=9D so the AS can indicate its policy to clients. 



I think the best place to define this parameter would be JAR, if that is no=
t possible any longer, we could use a different PAR-specific name and add i=
t to PAR.



What do you think?



best regards,

Torsten. 



> On 1. May 2020, at 17:56, Mike Jones <Michael.Jones=3D40microsoft.com@dmar=
c.ietf.org> wrote:

> 

> Works for me.

> 

>=C2=A0 

> 

> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt

> Sent: Friday, May 1, 2020 2:51 AM

> To: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g=
t;

> Cc: oauth <oaut=
h@ietf.org>

> Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
> 

>=C2=A0 

> 

> Filip=C2=B4s proposal works for me.

> 

>=C2=A0 

> 

> Are there any objections?

> 

>=C2=A0 

> 

> Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> s=
chrieb am Mo. 27. Apr. 2020 um 20:57:

> 

> While there are certainly different permutations and contexts of use t=
hat could be imagine, I tend to agree with Filip here in not seeing a stron=
g need to define new PAR specific metadata around signing/encryption of the=
 request object.

> 

>=C2=A0 

> 

> On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan <panva.ip@gmail.com> wrote:

> 

> Considering there's going to be a setting that forces clients to u=
se PAR (other mailinglist thread), then we should rely on the existing `req=
uest_object_signing_alg` presence to indicate a Request Object must be used=
 (as suggested by this upcoming OIDC Core errata), regardless of it being P=
AR or JAR. I don't see the need for a PAR specific metadata, for one - =
implementations wouldn't be easily able to re-use of existing pipelines=
, two - yes the contexts differ but do you think clients will be using both=
 channels at the same time? And even if so, the Request Object is the same =
therefore its applicable to both channels the same.

> 

> 

> Best,

> Filip Skokan

> 

>=C2=A0 

> 

>=C2=A0 

> 

> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt <torsten=3D40lodderste=
dt.net@dmarc.ietf.org> wrote:

> 

> Hi all, 

> 

> this is one of the topics we quickly flipped through in the virtual me=
eting last week. 

> 

> I see the following open questions:

> - Can the client require its instances to use request objects only.
> - Are there further requirements on the properties of these objects? S=
igned only, Signed and encrypted, algorithms? 

> - Can an AS require ALL clients to use request objects only? 

> - Further requirements here as well? 

> - Is this tied to PAR or relevant for JAR as well? 

> 

> In my opinion, client as well as AS should be able to control enforced=
 use of request objects. 

> 

> I could imagine the setting for JAR request objects (=E2=80=9Crequest&=
quot; parameter) and request objects in the PAR context differ, as the firs=
t case goes through the user=E2=80=99s browser whereas the PAR case goes di=
rect from client to AS via a TLS protected channel. I therefore feel the se=
ttings should be PAR specific. 

> 

> What do you think?

> 

> best regards,

> Torsten. 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> 

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

> 



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Thibault Normand
"Il existe moins bien mais c'e=
st plus cher !"
http://www.zenithar.org


--0000000000008aaf6b05a56e67e6--


From nobody Tue May 12 02:28:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3903A0D06 for ; Tue, 12 May 2020 02:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7DxoiOV3ScJ for ; Tue, 12 May 2020 02:28:10 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71CD3A090F for ; Tue, 12 May 2020 02:28:09 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 337993637 for ; Tue, 12 May 2020 09:28:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1589275685; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lc8SvHB4qMxfm22bzTtfv/NtHIhmP286SOFeAiqWDhE=; b=fMtyNbUKh2vWNM0iHsnuaE/2qzTP9L3NNaPjZoicwVmHP/vNT4NnC+jiKkIAaTyRDG9LAf +wYTF9HLSWap9KAqVEp+fDXgj6ly0nOysZx9HQVIkr4HT4SxD/V5vYoZKkJKYZSdpGxaXW Ux8Ws2FVLeidweDb5w1QFE5jg5yb9h8=
To: oauth@ietf.org
References:  
From: Daniel Fett 
Message-ID: <6ccdccc1-8dfc-965f-3780-6f0b857435c7@danielfett.de>
Date: Tue, 12 May 2020 11:28:04 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D5C3AB53A1A0F947529D27F1"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1589275685; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lc8SvHB4qMxfm22bzTtfv/NtHIhmP286SOFeAiqWDhE=; b=egc0qaby9n+dtjt22UMC4GMy6mokmhjPBhYtvbnwOaTFGyBZQJRMlNukijS0Za1v3n7LWZ 4wTHYWUW+njPkHgCvEMowGj5ZAw+EWdVKLE/vmEpxlUSXSyKjG4zIG54BzicF2FdcIEqhi Ohsn72SakLUryrTPGEYFctAMOgUKxRs=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1589275685; a=rsa-sha256; cv=none; b=Q62+cfJdH3Raxy7cuf91XB6hF8vWkUgopD7vhDMyLpU2AEmUaL326uFOaKMTbtCCs6znBO Au8sLSV0IxlCakqVWYoW3u6E2divC566GKdBAI3us0CRYbzRqHHztbnbsAdfVVib0RJb9H A/TEbgZqSeTbWPbNaZbPPQeSB7Ly73Y=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] Redirect URIs in draft-ietf-oauth-security-topics
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 09:28:11 -0000

This is a multi-part message in MIME format.
--------------D5C3AB53A1A0F947529D27F1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Indeed, we shall fix that.

Am 11.05.20 um 20:43 schrieb Brian Campbell:
> I suspect it was an unintentional oversight in the Security BCP and
> that it should be updated to allow for it.
>
> On Mon, May 11, 2020 at 10:03 AM Aaron Parecki  > wrote:
>
>     The Security BCP has pretty clear language around requiring exact
>     matching of redirect URIs now. 
>
>     https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2..1
>     
>
>     However the Native Apps BCP has an exception for localhost URIs to
>     allow variable ports. 
>
>     https://tools.ietf.org/html/rfc8252#section-7.3
>
>     Is the intention of the Security BCP to also prevent that use case?
>
>     If so, it should probably be spelled out explicitly, since there
>     is currently no mention of this. If not, then that exception
>     should also be repeated in the Security BCP, since it is currently
>     somewhat ambiguous whether the exception in the Native Apps BCP is
>     still allowed.
>
>     Aaron Parecki
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited..  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------D5C3AB53A1A0F947529D27F1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Indeed, we shall fix that.

    

    


    

    
Am 11.05.20 um 20:43 schrieb Brian
      Campbell:

    

    

      
      
I suspect it was an unintentional oversight in the
        Security BCP and that it should be updated to allow for it. 

      

      

      

        
On Mon, May 11, 2020 at 10:03
          AM Aaron Parecki <aaron@parecki.com> wrote:

        

        

          
The Security BCP has pretty clear language
            around requiring exact matching of redirect URIs now. 
            


            

            
            


            

            
However the Native Apps BCP has an exception for
              localhost URIs to allow variable ports. 

            


            

            
            


            

            
Is the intention of the Security BCP to also prevent
              that use case?
              


              

              
If so, it should probably be spelled out explicitly,
                since there is currently no mention of this. If not,
                then that exception should also be repeated in the
                Security BCP, since it is currently somewhat ambiguous
                whether the exception in the Native Apps BCP is still
                allowed.

              


              

              
Aaron Parecki

              


              

            

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

        

      

      

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

      

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


    

    


    

  


--------------D5C3AB53A1A0F947529D27F1--


From nobody Tue May 12 02:55:03 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D183A0D49 for ; Tue, 12 May 2020 02:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level: 
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDT-G8wo8fxL for ; Tue, 12 May 2020 02:54:59 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CF83A0D44 for ; Tue, 12 May 2020 02:54:58 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d87 with ME id dlut2200e4FMSmm03luugn; Tue, 12 May 2020 11:54:56 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 12 May 2020 11:54:56 +0200
X-ME-IP: 86.238.65.197
To: Vittorio Bertocci 
Cc: Jared Jennings , Benjamin Kaduk , "oauth@ietf.org" 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>    
From: Denis 
Message-ID: <0c7942f8-f94b-f0a9-cec1-cfa9803d4db6@free.fr>
Date: Tue, 12 May 2020 11:54:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------BF59C457E797090FEDF33352"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 09:55:01 -0000

This is a multi-part message in MIME format.
--------------BF59C457E797090FEDF33352
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Vittorio,

draft-ietf-oauth-access-token-jwt states in section 2.2.2:

This profile does not introduce any mechanism for a client to directly 
request the presence of specific claims in JWT access tokens,
  as the authorization server can determine what additional claims 
are required by a particular resource server by taking in consideration
  the client_id of the client, the scope and the resource 
parameters included in the request.

RFC 6750 states in section 3 :

  (...)

  Use of the "scope" attribute is OPTIONAL. The "scope" value is 
intended for programmatic use and is not meant to be displayed to end-users.

This has the following consequence: the end-user is usually not able to 
know which attributes correspond to a scope (or to a missing scope).
The only way to know is to look at the content of the token and the 
reason for doing this may be related a privacy consideration.

RFC 6749 states in section 1.4: "The string [access token] *is usually 
opaque* to the client".
However, this sentence does not mean : "The client *MUST NOT* inspect 
the content of the access token".
RFC 6749 does not contain a MUST, SHALL or SHOULD in the above quoted 
sentence. In such a situation,
we should not be "more royalist than the King"


Benjamin Kaduk wrote:

  "*I do in fact agree that token inspection by a client can be 
useful in at least some situations*".


This being stated, hereafter is a full text proposal replacement for the 
first paragraph (12 lines)
of the Privacy Considerations section (section 6):


  As indicated in RFC 6750, the "scope" value is intended for 
programmatic use and is not meant to be displayed to end-users.
  This means that, even when the client uses the scope parameter, the 
end-user will usually have no knowledge of the attributes
  which correspond to the scope (or to a missing scope parameter).

  RFC 6749 mentions that the string [access token] is usually opaque 
to the client. Hence, the client will not necessarily be able
  to inspect the content of the access token. As an example, an 
authorization server and a resource server might decide to change
  the access token format at any time.

  There are however cases, where the access token content presents 
privacy issues for a given scenario. In such cases,
  the end-user would like to know which attributes have been placed in 
a token before forwarding it to a resource server.
  If these attributes do not correspond to the expectations of the 
end-user or if the format of the access token is not understandable
  by the client, then the client SHOULD NOT forward the access token 
to the resource server.

Denis


> Its not really an interop issue either, given that following or not 
> following this requirement doesnt alter the shape of messages or 
> tokens. Its more of an architectural requirement, which preserves the 
> relationships between the OAuth2 roles involved and prevents the 
> confusion that might arise by the availability of data that 
> characterizes this particular scenario, but that doesnt change the 
> more general premises of the protocol. In terms of finding common 
> ground, I am not sure if visions as diametrically opposed as pitting a 
> MUST against a MUST NOT have much of an achievable common ground, 
> especially given that the MUST NOT stance already passed consensus in 
> the past year, and in more than one month of very public debate during 
> last calls, the MUST side had mostly one backer and more than one 
> opposed.
>
> *From: *Jared Jennings 
> *Date: *Monday, May 11, 2020 at 20:14
> *To: *Vittorio Bertocci 
> *Cc: *Denis , Benjamin Kaduk , 
> "oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> for OAuth 2.0 Access Tokens"
>
> Hi Vittorio,
>
> Yeah, this does make a bit of sense. So, the goal is to guide 
> implementors from making bad choices, not from a security perspective. 
> Meaning, it's not a security risk that a client does inspect or 
> analyze the token. Instead, it's is an interop issue and thus we are 
> guiding implementors to never assume or expect the token format to be 
> consistent or of a expected format, for various reasons. I kinda know 
> the answer to this question, but I am kinda asking this way to help 
> restate the intent of the "topic" and maybe help guide to a wording 
> that works for everyone.
>
> For example, as a consultant, it can be very helpful to know how to 
> decompile or inspect an "Object", but at the same time knowing that 
> such a method or practice should never be used in production.
>
> Jared
>
>
>
>     On May 11, 2020, at 19:24, Vittorio Bertocci
>     >
>     wrote:
>
>     Real world scenarios are full of situations where additional
>     assumptions can lower dangers that must be taken in consideration
>     in the general case, which might make less of a risk going against
>     the spec/in those particular circumstances/, but their existence
>     doesnt warrant relaxing guidance for the general case. A concrete
>     example: I worked on scenarios where resource servers wanted to
>     guarantee some degree of business continuity in case of AS outage,
>     which boiled down to RS willingness to accept ATs past their
>     declared expiration time, on the condition that the AS outage
>     condition was detectable and the staleness of the AT didnt cross
>     a tolerance threshold. The business scenario made sense, and the
>     implementer was within their right in deciding that disregarding
>     exp in those circumstances was acceptable. Nonetheless, I would
>     not argue that given the existence of that scenario, rfc7519
>     should turn its MUST NOT into a SHOULD NOT.
>


--------------BF59C457E797090FEDF33352
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Vittorio,

    


    

    

      
draft-ietf-oauth-access-token-jwt states
          in section 2.2.2:

          

        
          This profile does not introduce any mechanism for a client to
          directly request
          the presence of specific claims in JWT access tokens, 

           as the authorization
          server can determine what additional claims are required by a
          particular
          resource server by taking in consideration 

           the client_id of the client, the
          scope and the resource parameters included in the request.

        
          

          RFC 6750 states in section 3 :

          

           (...)

          

           Use of the "scope" attribute is OPTIONAL. The "scope"
          value
          is intended for programmatic use and is not meant to be
          displayed to end-users.

          

          This has the following consequence: the end-user is usually
          not able to know which
          attributes correspond to a scope (or to a missing scope). 

          The only way to know
          is to look at the content of the token and the reason for
          doing this may be related a privacy consideration.

          

          RFC 6749 states in section 1.4: "The string [access token] is
            usually
            opaque to the client". 

          However, this sentence does not mean :
          "The client MUST NOT inspect the content of the access
          token".

          RFC 6749 does not contain a MUST, SHALL or SHOULD in the above
          quoted sentence. In such a situation, 

            we should not be "more royalist than the
            King"

      


        

      
Benjamin Kaduk wrote:

            

             "I do in fact agree that token inspection by a client
              can be useful in at
              least some situations". 

          

      


          
        

      
This being stated, hereafter is a full
          text proposal replacement for the first paragraph
          (12 lines) 

          of the Privacy Considerations section (section 6):

        

      


        

      
 As indicated in RFC 6750, the "scope"
          value is intended for programmatic
          use and is not meant to be displayed to end-users.

           This means that, even when
          the client uses the scope parameter, the end-user will usually
          have no
          knowledge of the attributes 

         which correspond to the scope (or to a
          missing
          scope parameter). 

        

         RFC 6749 mentions that the string
          [access token] is usually opaque to the
          client. Hence, the client will not necessarily be able 

         to inspect the content
          of the access token. As an example, an authorization server
          and a resource server
          might decide to change 

           the access token format at any time.

        
        

         There are however cases, where the
          access token content presents privacy issues
          for a given scenario. In such cases, 

           the end-user would like to know which attributes
          have been placed in a token before forwarding it to a resource
          server. 

           If these
          attributes do not correspond to the expectations of the
          end-user or if the
          format of the access token is not understandable 

           by the client, then the client SHOULD NOT forward the
          access token to the resource server.

        
        

        

      
Denis

        

      

    

    

    

      
      
      
      

        
Its not really an interop issue either,
          given that following or not following this requirement doesnt
          alter the shape of messages or tokens. Its more of an
          architectural requirement, which preserves the relationships
          between the OAuth2 roles involved and prevents the confusion
          that might arise by the availability of data that
          characterizes this particular scenario, but that doesnt
          change the more general premises of the protocol. In terms of
          finding common ground, I am not sure if visions as
          diametrically opposed as pitting a MUST against a MUST NOT
          have much of an achievable common ground, especially given
          that the MUST NOT stance already passed consensus in the past
          year, and in more than one month of very public debate during
          last calls, the MUST side had mostly one backer and more than
          one opposed. 

        

        

          
From: Jared Jennings
              <jaredljennings@gmail.com>

              Date: Monday, May 11, 2020 at 20:14

              To: Vittorio Bertocci
              <vittorio.bertocci@auth0.com>

              Cc: Denis <denis.ietf@free.fr>, Benjamin
              Kaduk <kaduk@mit.edu>, "oauth@ietf.org"
              <oauth@ietf.org>

              Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web
              Token (JWT) Profile for OAuth 2.0 Access Tokens"

        

        

          

        

        
Hi Vittorio, 

        

          

        

        

          
Yeah, this does make a bit of sense. So,
            the goal is to guide implementors from making bad choices,
            not from a security perspective. Meaning, it's not a
            security risk that a client does inspect or analyze the
            token. Instead, it's is an interop issue and thus we are
            guiding implementors to never assume or expect the token
            format to be consistent or of a expected format, for various
            reasons. I kinda know the answer to this question, but I am
            kinda asking this way to help restate the intent of the
            "topic" and maybe help guide to a wording that works for
            everyone.

        

        

          

        

        

          
For example, as a consultant, it can be
            very helpful to know how to decompile or inspect an
            "Object", but at the same time knowing that such a method or
            practice should never be used in production.

        

        

          

        

        

          
Jared

        

        

          

          

            


              

              

            

              

                
On May 11, 2020, at 19:24, Vittorio
                  Bertocci <vittorio.bertocci@auth0.com>
                  wrote:

              

              

              

                

                  
Real world scenarios are full of
                    situations where additional assumptions can lower
                    dangers that must be taken in consideration in the
                    general case, which might make less of a risk going
                    against the specin those particular circumstances,
                    but their existence doesnt warrant relaxing
                    guidance for the general case. A concrete example: I
                    worked on scenarios where resource servers wanted to
                    guarantee some degree of business continuity in case
                    of AS outage, which boiled down to RS willingness
                    to accept ATs past their declared expiration time,
                    on the condition that the AS outage condition was
                    detectable and the staleness of the AT didnt cross
                    a tolerance threshold. The business scenario made
                    sense, and the implementer was within their right in
                    deciding that disregarding exp in those
                    circumstances was acceptable. Nonetheless, I would
                    not argue that given the existence of that scenario,
                    rfc7519 should turn its MUST NOT into a SHOULD NOT.

                

                

              

            

          

          

        

      

    

    


    

  


--------------BF59C457E797090FEDF33352--


From nobody Tue May 12 03:45:11 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6143A09BC for ; Tue, 12 May 2020 03:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui5abj3UC1Vv for ; Tue, 12 May 2020 03:45:08 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) (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 8DAEE3A09AF for ; Tue, 12 May 2020 03:45:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.73,383,1583154000";  d="scan'208,217";a="372748290"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 May 2020 20:45:03 +1000
Received: from wsapp5863.srv.dir.telstra.com ([10.75.131.32]) by ipcbvi.tcif.telstra.com.au with ESMTP; 12 May 2020 20:45:02 +1000
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5863.srv.dir.telstra.com (10.75.131.32) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 20:44:41 +1000
Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 12 May 2020 20:45:02 +1000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OKEi+UYm4ZuRYcsQUOJSRmWy1v1NJkCNuUdQKEqaHQx5jyHG/Usc9/O5MLa7l4qnz6xwfoND1h95xGsqQmri/273nIn5Gx8DXXQZ+XhYullW1xyHI3t729S04qtrzrBLzmbXkQpwHFG0FZvhpQ3oSjfZ535D+CUubdaDgPtXJEhVhF2PQOhWoB/W467ClJBA6l8pvlX5X+IIjX1UEfdm4UUs//wEfXoLTXztBhMGgUHs4UXMx6juTmykEBVU+BhVvGXuMmosAqYf+RJopjExFucbSENRNjkGnkU8+nXbKnUeixluB0hjIcAuZTK8d+xpAi4o/7qTQ46cHgABTBd+mQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L9UPEMgmfruAPtGPHHXraSTvz1cG4JQusQlbUYz7naA=; b=S5qE6MSuxA7HvxXpW57za4qetu2Q26wqd+s+xLvxWjCugFLJzpQ35kV0KC/HlWimKm9TUAefjn+WpDqiTyayrvdKaSfJUptGvFU9Q2EXWx0weN/fWA76KV6g9wrH17kWN4wl7An5aYkxsHFo38H1xNdekT7EJlCw3VG28sULKclv/YD1teMRNeHqpbaf7+SgEi8CsC3v28+8mLQG83NEO/yOKrQ0EZm7p+zbMzdF822Ji7OKbopy4j1biQSb2e3hj0ke230tc3+Vngh7Xu58rBYaZsn8Eniobkno8sfcKeNqC/oNL5emMAZc6LyFPMZKOh4uJhnhzfiH/7D//xVVqg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L9UPEMgmfruAPtGPHHXraSTvz1cG4JQusQlbUYz7naA=; b=vX7HqMZM5uMS4C6A3kM6B9Kf4F7KHaQbRz97B6rHB+D1075T1WCAA2JnnCCBFM5jNQZrnQiOOljrLLDsPn7qfO5KUPMs914JteAD3XkMKyR9DvEfnmZ5HD1nwJ/hpJMNMfgMVIq4L2IilU8K7A1zmyALSabY+hlbwI9eGD9PB3Y=
Received: from MEXPR01MB1702.ausprd01.prod.outlook.com (2603:10c6:200:16::7) by MEXPR01MB2086.ausprd01.prod.outlook.com (2603:10c6:200:14::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Tue, 12 May 2020 10:45:02 +0000
Received: from MEXPR01MB1702.ausprd01.prod.outlook.com ([fe80::4d7:1b54:6ee:bb6a]) by MEXPR01MB1702.ausprd01.prod.outlook.com ([fe80::4d7:1b54:6ee:bb6a%3]) with mapi id 15.20.3000.016; Tue, 12 May 2020 10:45:01 +0000
From: "Manger, James" 
To: Denis , Vittorio Bertocci 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AQHWE1gGZMyrQ8qcS0qZND1RXU6Qz6iQWrGAgAAd5wCAAQopAIAGCOCAgABNT4CABzkQAIAD6DkAgAAPooCAALboAIAAL3MAgAAoywCAAEcSAIAABu/Q
Date: Tue, 12 May 2020 10:45:01 +0000
Message-ID: 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>     <0c7942f8-f94b-f0a9-cec1-cfa9803d4db6@free.fr>
In-Reply-To: <0c7942f8-f94b-f0a9-cec1-cfa9803d4db6@free.fr>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.1.100.23
dlp-reaction: no-action
authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=team.telstra.com;
x-originating-ip: [144.132.40.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 76ab0e64-a647-401d-daca-08d7f6618628
x-ms-traffictypediagnostic: MEXPR01MB2086:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0401647B7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hJhFuwQukGfZ4m1CIHS5xcApw/5SnwY+Alv44giHPFm6JmdKuVM4J00yLHJ7yTx7Uhfs2/E4MUIgrXzSpCJa27FLze0SnADeo88iAV1MGShbpSlNhFeh7ibmb4VjwM/6F28G/c30mU13fUO7DkQkIy0oU68YcJzHvRi8F4kmuWkrUL493PyvbAbUqhL80HVgLc6RNBHCMGM6Ugd10nwAd3b7Ru/Za9CpTS8p1NOJ1Rfxs+2qEJHzj9tJorJ+UIXZtfltipn7fmvl5APIIlNnT6OC4oKpX57nYBV0qu1+n7mD5um1vP68QGGDL3HTf/SgmuvhK1pDw6f7EjC+afQDxdtcAptxe0BahRdKSQhR3iHdwacn5J6RaNH1jRzdFFnzBCPM3/b5ZDf2FzjOFSMnFUtzgRVNMwMT2rzGJvhE27d9t6BPihu/t7/Mef4krpXuUadxQ2WZLNMgIWIE2JtLdSdbH1WwvXoP1zWvbVmKvEBSVZCmaR+VQB3jVnT+lZngnP3kf5JRaf/3vrCdx3XDTg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MEXPR01MB1702.ausprd01.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(396003)(366004)(136003)(33430700001)(7696005)(110136005)(478600001)(2906002)(52536014)(66556008)(76116006)(66476007)(33440700001)(66446008)(66946007)(33656002)(64756008)(53546011)(26005)(55016002)(8936002)(8676002)(186003)(86362001)(4326008)(71200400001)(6506007)(9686003)(316002)(5660300002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: lkKsgOEAwN4r22iAqN6xm+7XxAl8XWuKpjDE1KbunZidPuNV2Sy4qE4+R/R5YkAM9sAhy0CFcL5ZADSswp8LxJC0JHTB7K7v6waQ5KcBzaGMWphQs7Kj4uTj7NvtpmEBpfk8401PhRCLemkYTpbeAZgJRWXEXCLwuNSqHXdisvNMmwPncB4Zo7yj9V55TCWAvC6O6BQTcBJo1c94ugCVDu4BdCiVMAs1AtVmmfeaZjTyeAuFdCblEqdAhXu5oL/8YPVme1TXMEe9TwClCrCfwftDlJWjc+R4oGqcXGOc/eCzvEWkeFSrnY2dORcpzvomr/7joE30TOqy1GC53RttXdrmZheLr8XenmByPfX8USO/PdBb7mifDe3fokG3f7rJlz2ijDeadamqcuBt9ekUhYttAMYphXzy5X818F7d2ZnZ8jCm+Iep44mzBA2y/TfoVMXQDlm4s/DuPIBcFxCVbZJ4EM/ZZvvJdzbAuQ5rlps=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MEXPR01MB1702E09FD7E18BF36B05A05DE5BE0MEXPR01MB1702ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 76ab0e64-a647-401d-daca-08d7f6618628
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 10:45:01.7970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lqVenK9dzEXIe4r9DnmpB6HFjjfkiJGxQf4IYqCytW/fdYPyO8tCDCPPjRUoupMpvLtKlnMb4/SyZppjWR2VMb5oGsenYw6O/qYm6M7BWGw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB2086
X-OriginatorOrg: team.telstra.com
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 10:45:10 -0000

--_000_MEXPR01MB1702E09FD7E18BF36B05A05DE5BE0MEXPR01MB1702ausp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That text is an poor suggestion, Denis.

> end-user will usually have no knowledge of the attributes which correspon=
d to the scope

The OAuth model is that the Authorization Server is responsible for informi=
ng the end-user about what is going on. That's why they display consent pag=
es showing what will be disclosed, often giving the end-user control over t=
his.

> the end-user would like to know which attributes have been placed in a to=
ken ...
> ... if the format of the access token is not understandable by the client=
, then the client SHOULD NOT forward

A major point of OAuth is to protect end-users from clients. The end-user h=
as to trust the Authorization Server (they sign-in there), but that can les=
sen the trust required in clients.

A client that inspects an access-token in the hope of preventing an Authori=
zation Server from disclosing too much to a Resource Server is kidding itse=
lf (and kidding the end-user). The access-token might be a JWT with minimal=
 claims, then the RS calls the AS's token-inspection API and gets back squi=
llions of claims.

So, by all means, do some auditing of Authorization Servers, Resource Serve=
rs, and the tokens they exchange to improve your confidence that they are b=
ehaving as they say. But if you write a client to do that inspection as sta=
ndard behaviour then don't call it OAuth-compliant. It will break when the =
Authorization Server choses to change its token format. Because your client=
 has violated a MUST in the best practices it will be clear where the respo=
nsibility for broken interop lies. And the rest of the ecosystem can hope t=
hat such clients are not prevalent enough to harm ongoing evolution of the =
rest of the system.

--
James Manger

From: OAuth  On Behalf Of Denis
Sent: Tuesday, 12 May 2020 7:55 PM
To: Vittorio Bertocci 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"
...
This being stated, hereafter is a full text proposal replacement for the fi=
rst paragraph (12 lines)
of the Privacy Considerations section (section 6):

    As indicated in RFC 6750, the "scope" value is intended for programmati=
c use and is not meant to be displayed to end-users.
   This means that, even when the client uses the scope parameter, the end-=
user will usually have no knowledge of the attributes
   which correspond to the scope (or to a missing scope parameter).

   RFC 6749 mentions that the string [access token] is usually opaque to th=
e client. Hence, the client will not necessarily be able
   to inspect the content of the access token. As an example, an authorizat=
ion server and a resource server might decide to change
   the access token format at any time.

   There are however cases, where the access token content presents privacy=
 issues for a given scenario. In such cases,
   the end-user would like to know which attributes have been placed in a t=
oken before forwarding it to a resource server.
   If these attributes do not correspond to the expectations of the end-use=
r or if the format of the access token is not understandable
   by the client, then the client SHOULD NOT forward the access token to th=
e resource server.
Denis




--_000_MEXPR01MB1702E09FD7E18BF36B05A05DE5BE0MEXPR01MB1702ausp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











That text=
 is an poor suggestion, Denis.


&nbs=
p;


> =
end-user will usually have no knowledge of the attributes which correspond =
to the scope


 


The OAuth model is that the Authorization Server is res=
ponsible for informing the end-user about what is going on. That’s wh=
y they display consent pages showing what will be disclosed,
 often giving the end-user control over this.


 


> the
end-user would like to know which attributes have been placed in a t=
oken …


> … if the format of the access token is not u=
nderstandable by the
client, then the client SHOULD NOT forward


&nbs=
p;


A major p=
oint of OAuth is to protect end-users from clients. The end-user has to tru=
st the Authorization Server (they sign-in there), but that can lessen the t=
rust required in clients.


&nbs=
p;


A client =
that inspects an access-token in the hope of preventing an Authorization Se=
rver from disclosing too much to a Resource Server is kidding itself (and k=
idding the end-user). The access-token
 might be a JWT with minimal claims, then the RS calls the AS’s token=
-inspection API and gets back squillions of claims.


&nbs=
p;


So, by al=
l means, do some auditing of Authorization Servers, Resource Servers, and t=
he tokens they exchange to improve your confidence that they are behaving a=
s they say. But if you write a client
 to do that inspection as standard behaviour then don’t call it OAuth=
-compliant. It will break when the Authorization Server choses to change it=
s token format. Because your client has violated a MUST in the best practic=
es it will be clear where the responsibility
 for broken interop lies. And the rest of the ecosystem can hope that such =
clients are not prevalent enough to harm ongoing evolution of the rest of t=
he system.


&nbs=
p;




--


James Manger




&nbs=
p;






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Denis

Sent: Tuesday, 12 May 2020 7:55 PM

To: Vittorio Bertocci <vittorio.bertocci@auth0.com>

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






…






This being stated, hereafter is a full text proposal replacement for =
the first paragraph (12 lines)


of the Privacy Considerations section (section 6):


 


=
    As indicated in RFC 6750, the "scope" value is=
 intended for programmatic use and is not meant to be displayed to end-user=
s.

   This means that, even when the client uses the scope parameter=
, the end-user will usually have no knowledge of the attributes


&nb=
sp;  which correspond to the scope (or to a missing scope parameter).




&nb=
sp;  RFC 6749 mentions that the string [access token] is usually opaqu=
e to the client. Hence, the client will not necessarily be able


&nb=
sp;  to inspect the content of the access token. As an example, an aut=
horization server and a resource server might decide to change


   the access token format at any time.



&nb=
sp;  There are however cases, where the access token content presents =
privacy issues for a given scenario. In such cases,


   the end-user would like to know which attributes have been pla=
ced in a token before forwarding it to a resource server.


   If these attributes do not correspond to the expectations of t=
he end-user or if the format of the access token is not understandable


   by the client, then the client SHOULD NOT forward the access t=
oken to the resource server.


Denis








 








--_000_MEXPR01MB1702E09FD7E18BF36B05A05DE5BE0MEXPR01MB1702ausp_--


From nobody Tue May 12 05:40:38 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8573A0885 for ; Tue, 12 May 2020 05:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level: 
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Upcv_gb8vYTb for ; Tue, 12 May 2020 05:40:33 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C313A0864 for ; Tue, 12 May 2020 05:40:32 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d69 with ME id dogS2200G4FMSmm03ogTVR; Tue, 12 May 2020 14:40:31 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 12 May 2020 14:40:31 +0200
X-ME-IP: 86.238.65.197
To: "Manger, James" , Vittorio Bertocci 
Cc: "oauth@ietf.org" 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>     <0c7942f8-f94b-f0a9-cec1-cfa9803d4db6@free.fr> 
From: Denis 
Message-ID: 
Date: Tue, 12 May 2020 14:40:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------95A2BBF890C1FC5129153040"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 12:40:35 -0000

This is a multi-part message in MIME format.
--------------95A2BBF890C1FC5129153040
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi James,

You wrote: "Because your client has violated a MUST in the best 
practices". It seems that you are already taking your wish as granted.
However, this is exactly the point we are discussing.

You wrote: "The end-user has to trust the Authorization Server (they 
sign-in there)". The end-user does not trust the AS for everything,
but only with respect to some activities. Please remember a definition 
of trust present in ISO/IEC 13888-1. 3.59.

    trust : relationship between two elements, a set of activities and a
    security policy in which element x trusts element y
    if and only if x has confidence that y will behave in a well defined
    way (with respect to the activities) that does not violate
    the given security policy.

You wrote: "The access-token might be a JWT with minimal claims". Yes 
indeed, however the end-user may not know it.

You wrote "a client to do that inspection as standard behaviour". No, 
token inspection is not a standard behaviour.
It happens if, and only if, the end-user has some privacy concerns. 
Please reconsider the text proposal which does make
that point:

  There are however cases, where the access token content presents 
privacy issues for a given scenario. In such cases,
  the end-user would like to know which attributes have been placed in 
a token before forwarding it to a resource server.
  If these attributes do not correspond to the expectations of the 
end-user or if the format of the access token is not understandable
  by the client, then the client SHOULD NOT forward the access token 
to the resource server.

Denis

> That text is an poor suggestion, Denis.
>
> > end-user will usually have no knowledge of the attributes which 
> correspond to the scope
>
> The OAuth model is that the Authorization Server is responsible for 
> informing the end-user about what is going on. Thats why they display 
> consent pages showing what will be disclosed, often giving the 
> end-user control over this.
>
> > the *end-user* would like to know which attributes have been placed in a 
> token 
>
> >  if the format of the access token is not understandable by the *client*, then the client SHOULD NOT forward
>
> A major point of OAuth is to protect end-users from clients. The 
> end-user has to trust the Authorization Server (they sign-in there), 
> but that can lessen the trust required in clients.
>
> A client that inspects an access-token in the hope of preventing an 
> Authorization Server from disclosing too much to a Resource Server is 
> kidding itself (and kidding the end-user). The access-token might be a 
> JWT with minimal claims, then the RS calls the ASs token-inspection 
> API and gets back squillions of claims.
>
> So, by all means, do some auditing of Authorization Servers, Resource 
> Servers, and the tokens they exchange to improve your confidence that 
> they are behaving as they say. But if you write a client to do that 
> inspection as standard behaviour then dont call it OAuth-compliant. 
> It will break when the Authorization Server choses to change its token 
> format. Because your client has violated a MUST in the best practices 
> it will be clear where the responsibility for broken interop lies. And 
> the rest of the ecosystem can hope that such clients are not prevalent 
> enough to harm ongoing evolution of the rest of the system.
>
> --
>
> James Manger
>
> *From:*OAuth  *On Behalf Of *Denis
> *Sent:* Tuesday, 12 May 2020 7:55 PM
> *To:* Vittorio Bertocci 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> for OAuth 2.0 Access Tokens"
>
> 
>
> This being stated, hereafter is a full text proposal replacement for 
> the first paragraph (12 lines)
> of the Privacy Considerations section (section 6):
>
>  As indicated in RFC 6750, the "scope" value is intended for 
> programmatic use and is not meant to be displayed to end-users.
>  This means that, even when the client uses the scope parameter, the 
> end-user will usually have no knowledge of the attributes
>  which correspond to the scope (or to a missing scope parameter).
>
>  RFC 6749 mentions that the string [access token] is usually opaque 
> to the client. Hence, the client will not necessarily be able
>  to inspect the content of the access token. As an example, an 
> authorization server and a resource server might decide to change
>  the access token format at any time.
>
>  There are however cases, where the access token content presents 
> privacy issues for a given scenario. In such cases,
>  the end-user would like to know which attributes have been placed 
> in a token before forwarding it to a resource server.
>  If these attributes do not correspond to the expectations of the 
> end-user or if the format of the access token is not understandable
>  by the client, then the client SHOULD NOT forward the access token 
> to the resource server.
>
> Denis
>


--------------95A2BBF890C1FC5129153040
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi James,

    


      

    
You wrote: "Because your client has
          violated a MUST in the best practices". It seems that you are
          already taking your wish as granted. 

          However, this is exactly the point we are discussing.

    


        

    
    
You wrote: "The end-user has to trust
            the Authorization Server (they sign-in there)". The end-user does not
                trust the AS for everything, 

                but only with respect to some activities.
            Please remember a definition of trust present in  ISO/IEC 13888-1.
                  3.59.

    

      
trust : relationship between
              two elements, a set of activities and a security policy in
              which element x trusts element y 

              if and only if x has confidence that y will behave in a
              well defined way (with respect to the activities) that
              does not violate 

              the given security policy.

          

      You wrote: "The access-token might be a
          JWT with minimal claims". Yes indeed, however the end-user may
          not know it.

    

      


          

      
You wrote "a client to do that
              inspection as standard behaviour". No, token inspection is
            not a standard behaviour. 

            It happens if, and only if, the end-user has some privacy
            concerns. Please reconsider the text proposal which does
            make 

            that point:

            

          

      
 There are
          however cases, where the access token content presents privacy
          issues for a given scenario. In such cases,
          

           the end-user would like to know which attributes have been
          placed in a token before forwarding it to a resource server.
          

           If these attributes do not correspond to the expectations
          of the end-user or if the format of the access token is not
          understandable
          

           by the client, then the client SHOULD NOT forward the
          access token to the resource server.

      


        

      
Denis

      


      

    

    

      
      
      
      

        
That
            text is an poor suggestion, Denis.

        

        
>
          end-user will usually have no knowledge of the
            attributes which correspond to the scope

        

        
The OAuth model is that the Authorization
            Server is responsible for informing the end-user about what
            is going on. Thats why they display consent pages showing
            what will be disclosed, often giving the end-user control
            over this.

        

        
> the
            end-user would like to know which attributes have
            been placed in a token 

        
>  if the format of the access token is not
            understandable by the
            client, then the client SHOULD NOT forward

        

        
A
            major point of OAuth is to protect end-users from clients.
            The end-user has to trust the Authorization Server (they
            sign-in there), but that can lessen the trust required in
            clients.

        

        
A
            client that inspects an access-token in the hope of
            preventing an Authorization Server from disclosing too much
            to a Resource Server is kidding itself (and kidding the
            end-user). The access-token might be a JWT with minimal
            claims, then the RS calls the ASs token-inspection API and
            gets back squillions of claims.

        

        
So,
            by all means, do some auditing of Authorization Servers,
            Resource Servers, and the tokens they exchange to improve
            your confidence that they are behaving as they say. But if
            you write a client to do that inspection as standard
            behaviour then dont call it OAuth-compliant. It will break
            when the Authorization Server choses to change its token
            format. Because your client has violated a MUST in the best
            practices it will be clear where the responsibility for
            broken interop lies. And the rest of the ecosystem can hope
            that such clients are not prevalent enough to harm ongoing
            evolution of the rest of the system.

        

        

          
--

          
James Manger

        

        

        

          

            
From: OAuth <oauth-bounces@ietf.org>
                On Behalf Of Denis

                Sent: Tuesday, 12 May 2020 7:55 PM

                To: Vittorio Bertocci
                <vittorio.bertocci@auth0.com>

                Cc: oauth@ietf.org

                Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web
                Token (JWT) Profile for OAuth 2.0 Access Tokens"

          

        

        

        

          

            
This being stated, hereafter is a full text
                proposal replacement for the first paragraph (12 lines)
                

                of the Privacy Considerations section (section 6):

            

            
 As indicated in RFC 6750, the "scope"
                value is intended for programmatic use and is not meant
                to be displayed to end-users.

                 This means that, even when the client uses the scope
                parameter, the end-user will usually have no knowledge
                of the attributes
              

               which correspond to the scope (or to a
                missing scope parameter).
              

              

               RFC 6749 mentions that the string
                [access token] is usually opaque to the client. Hence,
                the client will not necessarily be able
              

               to inspect the content of the access
                token. As an example, an authorization server and a
                resource server might decide to change
                

                 the access token format at any time.

              

               There are however cases, where the
                access token content presents privacy issues for a given
                scenario. In such cases,
                

                 the end-user would like to know which attributes have
                been placed in a token before forwarding it to a
                resource server.
                

                 If these attributes do not correspond to the
                expectations of the end-user or if the format of the
                access token is not understandable
                

                 by the client, then the client SHOULD NOT forward the
                access token to the resource server.

            
Denis

                

              

          

          

        

      

    

    


    

  


--------------95A2BBF890C1FC5129153040--


From nobody Tue May 12 06:50:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADCB3A09E9 for ; Tue, 12 May 2020 06:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG3gsqIQPt4b for ; Tue, 12 May 2020 06:50:36 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC903A09EA for ; Tue, 12 May 2020 06:50:36 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id c24so4603192qtw.7 for ; Tue, 12 May 2020 06:50:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=7gvhDaVej5cWDXk4NbO69Il1pEetOzB2AKqYbLPWK9w=; b=TFTlKm4hQLlrdAEC+tPC1xjXcuECpJBGp2H/cqk52ILL4bsOjSYoQK48uM+Austug5 Wwu/tNGKeRg84pyj28D7VxBG9pUrZIJI6lzVKCPMgGSzR9/goBbg+BK8cx1TA4L8S6FD PdqxOCbvvgOWqJt+pfcZITeu1s1uQbTmbScfvPr5tPcSxyhdfQgTv2UluQOK3W1xQUvd I/N3G2ExrWjWn9ac2sippGTWsY6NA1s4wY3OKTeyp+NNXvGWGjATiP9qdK97VyCx2LeP I/6OQ8qUwPpiDps1H7xFor5HSw03JgS8SGtP8uNSozluL0DekEz0LL7WMsl/mhLbXMHP 8VYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=7gvhDaVej5cWDXk4NbO69Il1pEetOzB2AKqYbLPWK9w=; b=POi3hIPnB2Zkbzyu4V5AgwZhoVh5tXfkBNci18spReb7TTUIcAsNghgBCdqVCR80Rv FfXvHhcpTkMawsECUE1USVUGw0uqbOx0LPjQZl8fzWTtyDRJQNFoHSTRyeTA3Mv/9LwZ eVOqQgJfFrf7SFc+dU4FR1bAEByeorohcT+pU0lSxpREqO9m+Fmcm7QAsbzmnA7rDP0r iPMnDS8G8ry7Y6A9rBJJYfHcMIRIC5rcEYUoCH1Z1vPbE3mRLFM5XXMBKE9zFJ3VgoOL /U5FIzyH79dgWZBKZIIalxUSZYveLaXL0FL1rBl6++sdMTy0NGnmSI9Dak6RsGW51N6f Xk5A==
X-Gm-Message-State: AGi0PuYOBLpxbpltIpsqdivFgi/sXzoNLdNqfGX9Ohk4ToGQF9aLZ+yU x6ImmLxdueTDahtg72kREumK7ExgmGM=
X-Google-Smtp-Source: APiQypLb1nlPOfsXZ1LOw23GFWMK3oMB29hEY/7PYywIVE+OQCAqQxjVChd7z8nqBBXxtEmyOO693w==
X-Received: by 2002:ac8:31ac:: with SMTP id h41mr21695509qte.139.1589291435355;  Tue, 12 May 2020 06:50:35 -0700 (PDT)
Received: from [10.62.64.152] (mobile-166-170-33-176.mycingular.net. [166.170.33.176]) by smtp.gmail.com with ESMTPSA id v37sm11975460qtc.7.2020.05.12.06.50.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 06:50:34 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-74024D46-E634-4C67-8AE1-A6E939641D5B
Content-Transfer-Encoding: 7bit
From: Jim Manico 
Mime-Version: 1.0 (1.0)
Date: Tue, 12 May 2020 09:50:33 -0400
Message-Id: <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>
References: 
Cc: OAuth WG 
In-Reply-To: 
To: Francis Pouatcha 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 13:50:38 -0000

--Apple-Mail-74024D46-E634-4C67-8AE1-A6E939641D5B
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Forgive me if this question is late or poor context, but wouldn=E2=80=99t OI=
DC be a better replacement for ROPC since it=E2=80=99s essentially a authent=
ication flow?

What use case for ROPC mandates OAuth2 over OIDC?

--
Jim Manico
@Manicode

> On May 11, 2020, at 11:00 PM, Francis Pouatcha  wrote:
>=20
> =EF=BB=BF
> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password=
 Credentials) with the following reasoning:
>=20
> Auth Code Grant:
> There are  many use cases on the market where redirection based flows do n=
ot work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the complexit=
y of user agents on non controllable client devices still make user agent re=
direction a challenge.=20
>=20
> Client Credentials Grant:
> Requires the registration of an oAuth client.
> - Citing the iot device use cases Beena which do not have a comfortable wa=
y to have iot devices register with AS.
> - This is a registration flow for the oAuth client role  and for the RO (R=
esource Owner). Remember resource owner credentials might be sourced from sy=
stem external to the AS  like company's LDAP. oAuth Client Credentials are g=
enerally managed by the AS.
> For these reasons, we shall not use Client Credential Grant to manage RO a=
uthorization.
>=20
> ROPC:
> Having an oAuth Client proxy the auth request of the RO to the AS only pre=
sents a security risk if the oAuth Client is a third party application. Ther=
efore, the decision on whether to accept ROPC for a specified client shall b=
e left to the AS. Discarding this use case will take a lot of business from o=
Auth servers back to the old market.
>=20
> Beside this, I mentioned in my previous post that there are use cases in t=
he market where permanent passwords are replaced with one time passwords.
>=20
> A lot of work is also being done in the direction of having the RO send si=
gned proof of ownership to the AS through the ROPC  flow using the password f=
ield.
>=20
> Therefore, I am ok with raising the attention of  implementers the same wa=
y we are doing with PKCE,  mentioning that ROPC  must only be used if  AS / o=
Auth Client can guarantee security of the RO credentials exposed to the oAut=
h Client.=20
>=20
> /Francis
> --=20
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-74024D46-E634-4C67-8AE1-A6E939641D5B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Forgive me if this question is late or poor=
 context, but wouldn=E2=80=99t OIDC be a better replacement for ROPC since i=
t=E2=80=99s essentially a authentication flow?

What use c=
ase for ROPC mandates OAuth2 over OIDC?

=
--
Jim Manico
@Manicode

=

On May 11, 2020, at 11:00 PM, Francis Pouatcha <=
;fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

=EF=BB=BF
I am against OAuth 2.1 discarding the use of ROP=
C (Resource Owner Password Credentials) with the following reasoning:

Auth Code Grant:
T=
here are  many use cases on the market where redirection based flows&nb=
sp;do not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, t=
he complexity of user agents on non controllable client devices still m=
ake user agent redirection a challenge. 

Client Credentials Grant:
Requires the registra=
tion of an oAuth client.
- Citing the iot device use c=
ases Beena which do not have a comfortable way to have iot devices register w=
ith AS.
- This is a registration flow for the oAuth client role&nb=
sp; and for the RO (Resource Owner). Remember resource owner credentials mig=
ht be sourced from system external to the AS  like company's LDAP. oAut=
h Client Credentials are generally managed by the AS.
For the=
se reasons, we shall not use Client Credential Grant to manage RO authorizat=
ion.

ROPC:
Having an oAuth Client proxy t=
he auth request of the RO to the AS only presents a security risk if the oAu=
th Client is a third party application. Therefore, the decision on whether t=
o accept ROPC for a specified client shall be left to the AS. Discardin=
g this use case will take a lot of business from oAuth servers back to the o=
ld market.

Beside this, I mentioned in my previous p=
ost that there are use cases in the market where permanent passwords are rep=
laced with one time passwords.

A lot of work is als=
o being done in the direction of having the RO send signed proof of ownershi=
p to the AS through the ROPC  flow using the password field.

Therefore, I am ok with raising the atte=
ntion of  implementers the same way we are doing with PKCE,  m=
entioning that ROPC  must only be used if  AS / oAuth Client can g=
uarantee security of the RO credentials exposed to the oAuth Client. 

/Francis
-- 
Francis Pouatcha
Co-=
Founder and Technical Lead at adorys

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

--Apple-Mail-74024D46-E634-4C67-8AE1-A6E939641D5B--


From nobody Tue May 12 07:14:41 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9B33A0A83 for ; Tue, 12 May 2020 07:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.262
X-Spam-Level: 
X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_SPAMMY_FILENAME=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL-JmBaltHRG for ; Tue, 12 May 2020 07:14:38 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650096.outbound.protection.outlook.com [40.107.65.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 915173A0A69 for ; Tue, 12 May 2020 07:14:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LfT7xL1eUvEtwfiZMJeDR/BkBXct5BdJeT39UD3ksG9UrN92/SP+/XLNNq1OnLnnPhbfFJGyT9xGg0pvGVgeArRMPZI1hW9Dm5GWIlHwJotZaHrpILK6UFFlBBb/uDablEE9oOUyweO5zSHw9x6ivh2EOoSU0oTosnJdbb0KW59Ay0C4zpoaXLwmHOhmKHBGrt6UfLdtYFR2v1UpRSnCUdMRhu0zzfgRajPFNfeR+A4Wi4yopdF6DjCbtpkYKgChQMY7l5uN62EUghh07AJBUYj4n0sf1LGraHpkB2Y+JiizhuxVLQz2zdBwhAeGh55OR2+jIscJXsYMTiGad2IXTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mPMGC/Fz4vox4kHQmBtF6mF+/wJavWSiwF94+6w2dYU=; b=J2qehbegWxzNZO2+XywyAE0NU+RwaUeVTuSazB9G9mFzZeHOavp9uoLnC1rrVuF4nE4PnEguK5weB/VTr8XiGTl3MV9K2QCpIAbDBuBcTbLBtt25wed50Xni9BLENLTZ68kUxMpWJFQWe0af2gGGkjFdVGu3PhaO4vnYontxARu7vxJZhebtJLXmJsdUd6TX7yoGnD5E06u8kMRgYYqKk73zJA3qfELDzH+yFj987VH4JjN7NICQid6sFWqjhEM9kKQPHED0KIDjE9b9YbVJi9bEG0u9EspGTNL+ZQjih0QoQJ5RIcAScY+mhoMTjeAaq4C1FVkIw0b9sowR5rIlVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mPMGC/Fz4vox4kHQmBtF6mF+/wJavWSiwF94+6w2dYU=; b=Nm9EUGT+bQx0ad1Az5Cm3IxEfCxL4QmnIW4oheMcSyeNcO+lGWzjz8FRqzAbPfE07eVQyR1qJ25N+A9z+N8XRRs2TH5YFSX27Wywgo5IEcSPc+d1NA62kbkF8Mj26Ab7Ddh6nMpHpZmjUf6KAtzoad2bBPhjxy8RADQpZNGud9A=
Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0462.namprd00.prod.outlook.com (2603:10b6:208:c2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3033.0; Tue, 12 May 2020 14:14:36 +0000
Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283%7]) with mapi id 15.20.3035.000; Tue, 12 May 2020 14:14:36 +0000
From: Tim Cappalli 
To: "oauth@ietf.org" 
Thread-Topic: Example of financial aggregator authorization
Thread-Index: AQHWKGbvNdpufhJbiUCmxwqRAWAyxA==
Date: Tue, 12 May 2020 14:14:35 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-12T14:14:37.685Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; 
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: [71.245.224.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 38d52223-777e-42e2-417d-08d7f67eccf9
x-ms-traffictypediagnostic: MN2PR00MB0462:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:1728;
x-forefront-prvs: 0401647B7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FInvEaQiwYvqPTzEj06PiTkbDVIasKtepuoUSIS8IHY9vx/laf4jSmpfn3V6gSY5LNVpsmVrqaWz5o/JaHua5h6zhPeyP7oZHGcjn6CL73tX+9dfEijYR771uE5rTjN/b6T6AJ4F3XvIb0A6gQVEO9PT2/Auyj8rq8r4PTOf+kbaKh3Z4hnlDCEgS6quCjpSNk0R5fdBc7WqC8i/t8LVBMtZkrZoOCVBC+gPIhMEaAshFThBQrkySarK2isXyL4KouQTwZCDj8rf7ZwnO3y4WB0nDQiAqBi+vujNr00R7dcJDB1RMvuHmTwkYtvz6V9JV5WAa49yAGIleoPgGC7Oi5O/IsixokBnIFDfjaVm/AW+qjimWbNoCjMKFuKWmlooHuI/cCEr04X0tj3ZgJ72MiPKMAn3jt5RIiO9Hm0fK8Gbc7RdDOZ+XJTvfarFuE3a/4yRknc0j43TsYeyq8lzArniSzajD9NuIgMZjP6/Pno=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(396003)(366004)(376002)(33430700001)(10290500003)(82950400001)(166002)(52536014)(33656002)(66446008)(71200400001)(6506007)(76116006)(7696005)(33440700001)(66476007)(66556008)(4744005)(64756008)(66946007)(66616009)(99936003)(186003)(5660300002)(8936002)(26005)(82960400001)(6916009)(316002)(86362001)(478600001)(19627405001)(8990500004)(8676002)(55016002)(966005)(2906002)(9686003); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: VAJAgdlR6dR4YmXpe7NRqLc6BSQreHHn9xlmqvuyXf82dYTwyywnj7H3OSkUPUGNqezKSwb0qt8hebYFFYNTkRyEVUCQOvRurlndKwiQ0qQuBlKH6ku82SW4NzDhVDSVvwarnTDx5LGbGJh0Wxp+o9yq9J4g/SITQVcLkz/V4tCFfqVYFL84JeIe6BAtLrXp2YgtxCL3Sbp6TOr1vdXd7v1I8xWQ3vg5+LVvwhaZ+FggkRIw6b9ESUwyO2CFJ0DC9QktTBF1hB3ZDDX47Ze6DA07EIuTFzt4CTieOaEusjySFcodsel5/vj5UjK+4gdXA+q6AUgS8270fStEjR6i3AGVE9HolRfpfhYpTIAdJbN4IiV9uWOPxQKFPPG9mPhmES69lTGwTZD1+A1NCOrvW4JWMHISvESYvZeOQP/qypU=
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38d52223-777e-42e2-417d-08d7f67eccf9
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 14:14:35.9900 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QIJmyeYm5MdNL1TWKlcFwwPwWUIYWO5N1qzx0MpQbV5b1WYpL7SW0yWwxzgpl8ujg6pNUsN2dtHSZW4KR0Hg1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0462
Archived-At: 
Subject: [OAUTH-WG] Example of financial aggregator authorization
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 14:14:40 -0000

--_004_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_
Content-Type: multipart/alternative;
 boundary="_000_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_"

--_000_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hey all,

As mentioned on the call yesterday, here's an example of Capital One's fina=
ncial data sharing flow for aggregators. Intuit's Mint is used in this exam=
ple but others like Simplifi (Quicken) also use this flow. Chase and Capita=
l One are the only two of my personal financial providers that provide dele=
gated authorization vs screen scraping with direct user credentials.

Screencast of flow and Capital One-side screenshots:
https://1drv.ms/u/s!AkYnERHf4_toguJP2ZSDduOgkha9Zg?e=3D3GWW2d

Data sharing link presented during consent:
https://www.capitalone.com/legal/datasharing-terms-conditions

Hope this helps.
tim


 Tim Cappalli | @timcappalli

[Microsoft logo]

--_000_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hey all,









As mentioned on the call yesterday, here's an example of Capital One's fina=
ncial data sharing flow for aggregators. Intuit's Mint is used in this exam=
ple but others like Simplifi (Quicken) also use this flow. Chase and Capita=
l One are the only two of my personal
 financial providers that provide delegated authorization vs screen scrapin=
g with direct user credentials. 









Screencast of flow and Capital One-side screenshots:












Data sharing link presented during consent:








Hope this helps.


tim

















 Tim Cappalli |<=
span> @timcappalli







3D"Microsoft














--_000_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_--

--_004_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_
Content-Type: image/gif; name="Outlook-Microsoft .gif"
Content-Description: Outlook-Microsoft .gif
Content-Disposition: inline; filename="Outlook-Microsoft .gif"; size=44334;
 creation-date="Tue, 12 May 2020 14:14:35 GMT";
 modification-date="Tue, 12 May 2020 14:14:35 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhqQA3APYAAP+4AH24AACl7/FQIGxsbHJycnBwcJGRkW5ubmlpaYiIiGpqbHBubvz8/ICA
gPT09ACf7Iq+HPNNHP707f/jkri4uMzMzPC7qMzjmfj4+Ht7e9fX15+fn9TU1Ojo6Ozs7KioqN35
//Dw8L29veLi4sTExPu/H62trZycnJaWlqOjo/X/84zb/HZ2du5HF7S0tO1cMuL5/2VlZXh4ePX7
6v/645mZmdDQ0J/d8yCt7eXl5dnZ2fvCJf/43ONeOMfHx9zc3B6n4+pLHsHBwd/f33R0dP7+9nh2
d/zp5P3rq+5WK/vPVBap7MnJyexvTP/59tToqfL9//70zP/865fFMvHDtJzd9/u8FGnH8EO366fP
UbXm9u1BEfOSde5iORij4OHxwfjbgwCl8fnZzf/38evz1bvYdMrYiO341gCZ6PL54ttYNONHGyyy
79mqf5rS2rXXyc3Ysyep4u/76r3e2dbJtNzev2xqaruFf8eRNv///wAAAAAAAAAAAAAAAAAAACH/
C05FVFNDQVBFMi4wAwEAAAAh/wtYTVAgRGF0YVhNUDw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0i
VzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6
bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuNi1jMTQwIDc5LjE2MDQ1MSwgMjAxNy8w
NS8wNi0wMTowODoyMSAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3Lncz
Lm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv
dXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5z
OnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4
bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOk9yaWdpbmFsRG9j
dW1lbnRJRD0ieG1wLmRpZDpkZTZkMzQ4Mi1iMWY2LTQ3ZDMtODA5YS1lMjM2OGYzMTljM2MiIHht
cE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6RTkyMUM2RkFFMTQ4MTFFODk1MDBFRjc4MDkyMTE0NEIi
IHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6RTkyMUM2RjlFMTQ4MTFFODk1MDBFRjc4MDkyMTE0
NEIiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENDIDIwMTggKE1hY2ludG9zaCki
PiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDoyNWJjM2M3NC1i
OTY3LTQ0MzMtOTkyZi02ZTM4Y2RhYWNmYWUiIHN0UmVmOmRvY3VtZW50SUQ9ImFkb2JlOmRvY2lk
OnBob3Rvc2hvcDpmOGVmNDM3Yy00YTQ1LWMyNDAtOTc0Ni04MzM1ZmNjNmZkNjciLz4gPC9yZGY6
RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4B
//79/Pv6+fj39vX08/Lx8O/u7ezr6uno5+bl5OPi4eDf3t3c29rZ2NfW1dTT0tHQz87NzMvKycjH
xsXEw8LBwL++vby7urm4t7a1tLOysbCvrq2sq6qpqKempaSjoqGgn56dnJuamZiXlpWUk5KRkI+O
jYyLiomIh4aFhIOCgYB/fn18e3p5eHd2dXRzcnFwb25tbGtqaWhnZmVkY2JhYF9eXVxbWllYV1ZV
VFNSUVBPTk1MS0pJSEdGRURDQkFAPz49PDs6OTg3NjU0MzIxMC8uLSwrKikoJyYlJCMiISAfHh0c
GxoZGBcWFRQTEhEQDw4NDAsKCQgHBgUEAwIBAAAh+QQFAwACACH+IENyb3BwZWQgd2l0aCBlemdp
Zi5jb20gR0lGIG1ha2VyACwAAAAAqQA3AAAHsYB6goOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpuc
nZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV
1tfY2dqoY1VjUGDbyE8XXHkBZuLIdXhuVGfqxg0sECAAYfHGOFlwSxT58vQYMQKwoMGDCBMqXMiw
ocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKMUFAgAh+QQFAwACACxMABYACgAJAAAHT4B6
TxOEZDRqakZ6SE6NblSQYIswLi5uAZiSSDBcXJeZeiJueHh1WqdSeiFtTExwJlc8qSFMYmIvAABX
SQ0hQRAQb1e6SXoxOMgkFElJPYEAIfkEBQMABAAsTAAVAAwADAAAB2iAVV0XXW5jZ2aJGEZdLo5C
bgGSAVQ0jQOYbhGTlZcDEpqcK11cji6hkpVVbqxudolmWmdGWDm2OXA8Jjw8S1NYEGLCbwDFADy0
EAJiEG9Xxr7Ay83Gx79ybW05dLy8vjHg4Bk15OQNgQAh+QQFAwAEACxJABMAEAAQAAAHm4B6E2OE
hRNlYImJaHpjPjCQkBdUEZWVZw1jAxKcEi4XEQGiomaNShIDqRKgo6JnpqiqrK2lY6epm7OjZplC
LkK+n6G0ekgXx8hEZ2dmzGdgelttOW3VbXRLPNraFNFMAuBiEG8mAObmYdHg62J05ecA6Vvf7OTw
8d7rAu3v5/IQAAPag5cuBJaDCEmECbNk4ZIkeiJKnCjRSMRAACH5BAUDAAQALEgAEQAUABMAAAfR
gHoNDXqFhnpGiYqJhE9dj11Oj05jZlqXmFplhU5cLi5Cn0JVVAGmpwFgek9OA66vo6WoARGqji6v
r6SztLZOuLmxvLWrXcC5u7PErBK5EhLJqMR6nULW1mzRp9NjdVXf4B9QGOTlGDSCWFnr7FlbS/Dx
8FJ6UVkQYmICAmIQdDwAAgq8Qs8ehH0IBWwBKDAgwXr3EvL719ChFCMGJYpZWBHAw4wJxVCsSBDj
PX378nEkWfAeEwEvX9JZ4vGKzSsmLurZwrMnzwdSkggNKrSGnkAAIfkEBQMABAAsRwAQABYAFgAA
B9qASBdVhIWEE2BQiotQGFBGF0IDk5QDQmNaAZqbmlSQEhKVAxKXmZybWiuRopMSmKebVKqsk6Ww
mqkXtKOvt7K6tLa3ubuuprCeF6CioL3IkELR0tFszqdaRkhjVWPb3dyIjIxgeltZ51lY6FkhYUvv
8O9hRlYQYvdi9vlbSwD+//54GMEBQYDBgwIg8AMIcMkUgggRLmTozyHEiAknUrRYEKMAjQw5elTY
jyIAix4Ngmz4EILLgi8h0ClJkccUc+vWtePxjucSnmGmRBlKtGgDI1OSKp1SY4qeQAAh+QQFAwAE
ACxFAA4AGQAaAAAH74ANE4OEhRMNNGqKi4w0E06QkZJOSGdUl5iZGI8uEp6fEi4uY1oBpqeoZ48S
A62urUJjZqi0AapOrK+usbO1p7e5ugO8vr+rwrCyxabAyMPKy83IxNHH06TLtpyg3NDFt0LO1N8N
Y+bn6GNPaGDt7WXuYDRRWPX291ghSUthS/7+/ZYkiZEDgsGDCLcsAcCwocMwMdoImEixokKHGAFQ
iFixo4CLGRtClOhxIoQQC0MyHFmSIkiVLEuKOZkSJseWH2uGjNkSpcqVN1u+3BlDDsKjNH8CCBPF
CounUKPGSBKmqtWrUvRo3cq1AdevXwMBACH5BAUDAAQALEMADQAdAB0AAAf/gARVXW6EhoWIE2Bm
jI2OjGgEbi4SlZaXQkhmAZydngERYE8XLgOmp6gDBJufn6EEXUKps5oEtre4oGCSsqq4twNIv8O6
BKSmw7bBybmvscjJy8y2xW4S0MPS07oNF73M2szFXde+2cLTBNXf0bXbzpbg6O+73kr3+PlKSGcE
Ef4A/0UoNgGJwYMIDRKgUaYMmocEHj4sM6cBgS1Y0hGIIcVWmI8fCYAM04MAljQCNIZJBwBARxYQ
UjKDEGLlNABXOmKJma4my5wEYMqcZpMZTp08p/m8CVQoM5lFkx01mZTZUqNNqw6DIPIn0qHJrkrN
KqCs2bMevVI9y1YAzTAtMePKbdn0C5O7ePMyqXnFhN+/gHl0jBFiS4jChw0jjlJDiuPHkB1PIWCR
sq3KlTX+CgQAIfkEBQMABAAsQQALACEAIAAAB/+AehNjhIWGhk80YIuMjYxlDXpjXkqVlpcwSj5I
GAERn6ChEQFaRnpIMC4Sq6ytEgOcAbKztLOlkjCvA7u8vBJKsbXCpKZjub3IA7/Bw7S3k7rJu8ud
zc7Fx9LTwNXWss9e0dLU3rbY4snk5cSS4drbzN7P2drq5eDoyPby5+/K3OvYGVPlyhWsbvxOUYLB
sKFDTUigeBJF8VaDCUgyatyosYGROSBDigxJQ4+eGCxSqly5MoaUMDBjyoyZxFSILxBy6typMwQF
AECDCg26ZEqDEEwEKF3KdKnPoVCBLrGZtKlVAU+jDi16tOpVplm1EqX6tWlYsQC4Ii0L9idaqWRQ
2So9K1atV7Z0tU7Vs1YuVrdv7fr9+xYu37tl80YV7Fcx1L0heEruCRitWixYsmTerLkzlhBJloge
TXp0GFMNokQxybp1g9cmjcieTZu2nkAAIfkEBQMABAAsQAAJACMAIwAAB/+AeoKDhIWGh4NGikZ6
F05dkI+RkF2SE2BamZqbnFANXVwuoRIupaShokpIUAGtrq+wGHpdLgO2t7i2EjCrsL6vsrS5wwO7
vb+/wbXEuMasyL7KzM28z9DAs8vTxdXXsdnbut3ertLhzuTl4Ofj6ebb6OkB79Px7uvw7eT0zPb7
2RICChwY0IUqa/+6KIHBsKHDhl4mQIlAsaLFi7KekNnIsaNHQStCihxJsoGeLSyssEjJUqXLlFF6
UJhJs6ZNKXqwpIHAs6fPnl9CJAFAtKjRoxQaYIEgoKnTp06ZCD1K1SiFnEyhahUgdWjVqleXbtXa
9StYrGOhljWLFG3aqFNF2Vp1+5ZrXLlEw2atuxYvAL11m/bFCzjwYLmF+d4lTPftYbaJHS9G3Djt
Y7N6f2rmefnr1S04QosePXpLzCSoU6teLSUQACH5BAUDAAQALD8ACAAmACUAAAf/gARIg4SFhoMN
RmiLjI2OaGoET04wXpaXmJcwThNgEZ+goaIRWgRkXi4Sqqusqy4wSAQBs7S1tgGlZE4SA72+v74S
MARgBMbHyMm4pk4uA8nQyMXR0csTu8/U0NPayMu6zt3J3OKypde85cfk4t/N2ers3dbY6sby2u7h
9vjU9On87Jljti+ewH/wyvWrluudwIXQED48mAuVhIn2lk3KxBGTE2ICSRkzQrKkyZMkR5pMhDKl
sShbcOCIObNmTZpbCNRIwrOnz59JpBCIIicNBIEErtgDsMRIlDYCBCAVyHQoVKkClapj6vSqQKFL
l1iNOjVsV7L2wG4V+xRtWXFcUNtiVae2XFW5b+02xZuWKluvebvFBUzX79i5gaMNdluuLty/USNL
nozYbJQcEDJr3sz5S4gkAEKLHk36LpbTqFOrPh2jx5LXYV7Lni2bAoFAACH5BAUDAAQALD8ABwAm
ACgAAAf/gE9kT4SFhodPBARGK42Oj5ArRl1eTpaXmJiVE2hUnp+goVQRZk5cEqipqqouMEgEAbGy
s7SxWk4SA7q7vLwSimiKwsPEigG3LgPFy4oTBBHMy8e4ytHEztbFAaXJ2cMTZd7D07nizc/msMjV
4tjp5OzeztDm207d5u71t+X56Pv34mXTJw5eunnvuAm0RtCbQX/0Cq47mM4Ysl/iYFS0SMkSAY8g
nXwUCYwKAVEoR5kxUlGPsAbCWDIzwnILgS02cd68mZOnoikVk0jJkgaCuDRBCEhRdEVY06cEoAJY
ksVoRSlNzU2tunFpuq1WK2YVB7brWG9lN57NljYd1q9UYMOmW2utrbm3WuNujAqX61W60eyaA8xM
sDe8ZPWq7StXHGK0cQVInky5MhOlhJdtLQqhs+fPn5mEkAKgtOnTqEsvwYEFCwvXsF/Ljh2lRpjb
uHPrvp3kZYPfwIMD3yssEAAh+QQFAwAEACw+AAcAKQAoAAAH/4BjF4OEhYaETzQYZ4yNjo+MagRV
bFyWl5iZXDAEBAGfoKGioGCTQgOoqaqrEl4TaBGdsrO0nQGlVRIDtbydrgSxvby3prvCtF4EaMfD
uLrMs8nL0LPEVafUvsrB2dbP2dIB2ba42ODb457OxtTh6dbm7ejj3uzQ7vTl9szS3NT14/B10xdw
3sBJ3+RNy1esIKx3uFxISPcqnbpJTpx00kiAo8eNs6hko0KljEVaevQQ0NMgZcoGLVMSaDArxslO
UtIlmUIARxoI6WwSuDL0CtGjQ5MezYkDgoBsYnLcBMDU6TipJ6k2aPo0G1aLVHta9TpVytax1L6m
C8v1qtC1Zmbben07ji1aaDnoZtMqN61eana7+s0a9y6zvITFCsb7Fxpfw8cQg626+HBjZo8rR758
LLCAz6BDi5ZFtG7cL0xSq17NmkmbGFJMGJ1Nu/bsnFFC6N7Nu7fuGA2M9BhOvLhx4kYIBAIAIfkE
BQMAAQAsPgAHACkAKQAAB/+AVU5dg12EhoeGhV1kAVqPkJGSkFABXVwumQEBmpwum5pKm6OkpaZm
lp+mq6ytpmeWrrKzpbBdqrS5rLa6pRG9Aba4wMC8xAG/vcLHxMbEybrLzMqxx9C50tPY1c/FqdrR
3OCz2eOuzubnARdexGrAERjpepsNpnpGpCHgUgH9/gAD9usRAAswOZtMbAKwsKHDAADCFEw3S6JB
iq7C6LmIkZXFjq00cgRZ6iOwfcREEkMJzGQvlr1UnjzmUhdMXTJf0pw4M+XGlTtH5rqZK6fNoAHE
KF3KVCmpHMxEpoFAtarVqxCCbLoCoKvXr2C7StyCo6zZs2jLbokyJYnbt3AK4779R5KUvVGBAAAh
+QQFAwABACw9AAcAKQApAAAHlYABFwGEAU6Fh4SJhgETaoWQkZKTLi6ElZeWhDCTnZ6foKGUoqSf
ZqWooZqprKesr5GrsKSus7CytqC1uam4vJ27v6S+wpHBxaDEyITHy51czpNmDdGTVITUuUZGAXqE
3oXgyElS1Z8AVwEAAVfr6ebw8fLz9PX29/j5+vv8/f7FaQKEqIejEIUABxMiXKiQQpl54gIBACH5
BAUDAAEALD0ABwApACgAAAfdgAFjXQGEhoWIh11uZAFmj5CRkpBlARcBmJmam5ydnpgYTxdcn6Wm
nVCWpKesplCirbGfqaOytpqvl7e7tKu7srm/t73CwLDFscTIrMHLzKrOp83RpcrUntPXqJYBLtqo
et+eEWAB4eKYDdpJmOzu7fA1ASzCAAFXmPj49/mZSUb00G1iF1CgvwYFDQYgqPBgQoMMGy5EKHHh
vIpJKEqM2DDjQ4EcFXrEeHGjxo4XBahcyVKls5GxIASIEcAEP303c+JjF2OLz59Ag/7UY0RKEilS
AiA9mnSpUaNkAgEAIfkEBQMAAgAsPQAHACkAKAAAB/+AAhNVhIWGh4VPNFCMjY6PjTQCY2xsQpeY
mZlsPgICEZ6hoqOeEWV6Y0oSpKyeMAJgrbIRaJOqsri5o7Sot7qisb+htLZCwsekvKmryMHHxKnG
yNOfaL3Mx87C0ErS1M/Wy9Pav9zexwHIyr7f27XR1Ong1+3gxfXu9M3T0Of4uNCcUKuFjArBf6wa
yIqC8JcUIwK2fElD7coVYQBMSNGzRYCYhriuSIn4BWTIjRJNytJI8qNKUiI5lnxJiqVElzRDxUyZ
U5TNLzh77pzZ09PPoDmHFg11dKkApU6bLt3p1OhInr8gMPkmUkAIOTnCih1LNkcWTzxM8FjLtq1b
Hj0TBESZS7eu3bqepujdy7fvXj2BAAAh+QQFAwACACw9AAcAKQAoAAAH/4ACek9khYaHiIV6ejSN
jo+QjUZ6gl1KXpiZmptOAgJUEaGio6QRZg0CDU5cEq2ur68ungIBs7a3tlqUqrK4vgIwAmC/xLqp
Tr3EtsG0yrjGqhLOy8LTt8Z6yNaezLXbAtBO0tvBw9/glNnJ093n4ePW5efogtrknt7b4evO5RHu
u+zFE5bP2r5v/gAe46esXMFpB8khKfPQWcSB8+ip4nIOiblv0Lp48TRSQMmTJG39s2aKUkYjnozA
hClAps2bND25zJhk3q4s29IICBLCEwABR5MiXap0CaUoWSB8Y5JRgNNUUadWvQpV6jaqGa82yPp1
61Oy1sDOE4t2mtpzXFbbOnv7ja3XtGYFdNUa9uddt3n3lu2L9e/cwHKV0d1ml+/as+cWWxPbBoLl
y5gz2zpad5GeN1hCix5NOnSUHmFSq17NOsySJOk8y55NW5AenLhtehYQCAAh+QQFAwADACw+AAcA
KAAoAAAH/4ADeoOEhYaEA4KHi4WJY11ukJKRlJNuT2pmmpucnZplg24DLqSlpkIuqANKSImur7Cv
UIIXsbaxAbe3swO1ur/AsLN6F1zBuMeus08XbMnPscPF0Im5z8vN1NrSxtTWydjO2tDc2t/H4ePk
tN3Q58Hp6uDs1GDU2OPvwNLUE9u0Prx4GSCQ4MCCBROVSRShocOHDwfYE3SsQQNbFzMOyGhRTwM9
rkLgkJeshiAWySAM+PIKwACXMF/KdHklyQAjKJMJSGQTmk09LNKQPGYTp7aez34G1eYy6c2cPqkp
FToUWFGoTqMCpQqtabKrR6We5Fr1FlixWpdS80r0adi0ZTytPlXpk22wqQME6N3Ld++AIImuDBBM
eLDhwzVvxtjCuLHjx4wHTJGSRIrly5YrU748ZeggiiBDFzLiKhAAIfkEBQMAAQAsPgAIACcAJwAA
B/+AAQ1jhIWGh4QNK2CMjY6PYGV6AUgwA0qXmZibmT4BARGfoqOkAVRGlEoSq6ytrZ9IpbKjp3qV
ErOysbmyp5QwuLyju8K0RrbAxaLEyqaot82U0Z+10M3Myr7WytjF1cnX086/wdzi3+XF3cLa4ObT
6NHrvO3p4t7H2+rnz0ouzUrm5dLmRByYUM20oGpmZOGnBrIaLETVcGGULTgCZNyosSPHewEmxfgi
Lsk0Hnr0xGAiTgqAaDxQrSx5MuVMcS+bxQxwM1qSKzBtsgSpU+ZQnzVVHiUqbGfPZj+DKmWqzOlS
ZSalPqU6y2pJoDqFcm1qlKZWARDSql3LFqTTLHAm48qdmwXLpyV48+rdizel37+A/zZokLKi4cOG
U46dxDgkqUkBAgEAIfkEBQMAAQAsPwAIACYAJgAAB/+AeoKDhIWFRoiJiotGegENF06SXZOVTpSX
E2VanJ2en1pQgl1cAQEuLqepqKouSqawsbKxZnoNXamzuru8pmejbL3Cw7+3ucPIs796XcHJz7DF
uNDUy83U0NLH2MTA3Mna38jWzuK94ebn3um86Oy61qXv8LZdMPO6GI4N2Eam/gD9BfC3IsAKR44C
4FDIcKFDhVZM1YAmJYAeLGmQQYAF4FmYR1g2PksCLYygkNQ6JvvYACU+WSYvinwJi6XLZyqRxbyZ
LOcwmzN7ejwZlCbQlENlIl0Jsugwn8J2OsV3FBrUXlLFaBWD7CovmxmRfcEWc4uVs2jTqsURpQaF
t3AO48qlUBGaIFOG8g4yFQgAIfkEBQMAAQAsPwAIACUAJQAAB/OAAYKDhIWFeoiJiot6AXpIF5GS
k5QXT2oYmZqbnBg0AVUBLi6CpKKlhqmqAWh6oauwsYNooBKyt6pqrri8hbRVtr28Ea2vwry/wce3
usbLssnPssS70tC11rHN2bHR3KnUzt++oKa4UL3FuDABSL1UtI1P8/T19r0rRoIxVv3+//8C4BBE
IUDBgwYTInwSYMu4VFd66HH4sFDEhhUtSqSYUdBFjrwA4Io4seOgjyY9bkwZAKUwkbdIgszo0qRM
lijF9IIp66bOji4FCM24kUmOo0iTJm0jyITTp1Cj8ugRIEqMq1izao3RQE+Nr2DDiq2hJxAAIfkE
BQMAAAAsQAAJACQAJAAAB/+ADUiDhIWGSA1GZYuMjY5qehNOazCUaz6YPpWVSj4AABGhoqOkWpE+
LhKqq6yqAEoAUJ+ztLUAWkYTPhK2vZ+yvra4urzBtcDGs8O7yc2+y8XOyM3Qzr/Wt7nM1tPJ1c2w
2NnE2N3G38mw5sHozevP2tHG4djtye+9yy7i9blOMAADCgzI7xMuAE/IKFzIsOGnFRAjSoz4qQGA
KDisWQHQAwAFjyA/igQJwEiMIGkKOltiUo4Ylc1YxpADM2bLmslk0sQZTCfPnjd/9vIp1BbRorSO
Iv2kdGlTpDoFLJ31tKjMLxCyat3KlR/LKFiyYBlLtmzZGFKWqF3Ltm0YI3oR4uppQLeuXbpxAcjd
y3cvgEAAIfkEBQMAAAAsQAAJACQAJAAAB9qAeoKDhIWGh4cAem5OjY6Pj10AAFSVlpeYUAANXVyT
n6CfXAOhpaVngp2mpUqrrqhPXS6utLUAqHqqtq2atpOwsr7CoLi6ta3Dt3qxs8nCxZ7Cvb7Azc62
0NfUy8HatdnSw9Xe36nR5KuonMi1Xs4YeslP2npbLCwA+Pr7+ddSglnQ0QqjpwEWCAJXEdSTBWHC
UhQEHXwIEaBDip8WTsT4KSLDixw1gsTosSHHjBJHUiyp8qHIk5NYwgTwEmbJNL6+OFu4xQqOn0CD
Bo3Sg4LRo0iT/gOFiJC3QAAh+QQFAwAAACxAAAoAIwAjAAAH3oAAY11dboWHhomFZGVmjo+QkWV6
bgAul5iZQpdKAJ6foKGeUAAXoqeoqZ5glKqgna6hYKWxtaeslbWwtgCzprzAuLa7tr7Awa26x8bH
xcmxxLXMzbHCysG01LFQT7+2pMWeE+Pj4hMA5BNkx3qgLAAsVu/yAPTNPfDasUn5tQLH/Fik0acq
SYN3BFFdCTgw4SmDCB2GWgivoURQEC9OZKgR48GOnygKBOkpI0mRFjuajPUPWEAAAmLKnBkTABNg
FEWE2BJiZ0+ePn0CmCKlqNGjSKeEauCJKQCnTpsFAgAh+QQFAwAAACxAAAoAIwAjAAAH4YAASBeE
hYaHT2gYi4yNjVA0AFVsAEKWl5cAmkKanZ6fmhFokkISoKeoqKKkqa2uq1WcrrOgsLK0uAC2ubm7
vLS+v6+jscKzwcaqxLfJp8jNn8/QnbCUrqa8onpVa9OnVKMNZJ4TE5rmnei/IZ8smu4A8PC5UwBb
uBC8Jj1692Len/bZywfQ075+BQP2GJiw08F7tAToW7iFYMOHDR1StJgQY8SJDDN6FLkxI4CDONKY
vEJRTo6XMGPCbKPJBI+bOHPiXLIwSoyfQIMKbWCkR42jSJMeNWrkkx5NTwFEjSosEAAh+QQFAwAA
ACxBAAoAIgAiAAAHv4BkY4OEhYYANGCKi4yNDWNKQgCTlJWSSpWZmgBUNJCboKGanZASoqegpEqm
qK2UqqyurbCyrrS1qLe4orq7qZ6rvrzAscKjxMa/pcmbpJLMx2M+0Js0ABPUmzHZmUlGAF/clDxT
4pXk4OYAPN/h5uhfYu/t6vDy4uzp7+Xx8/r4/O5xy+cOIDiB2dhtgcCwocOHtciFyEKxosWLk3gs
WQJgY0eOIAGEmdJgRZSTKFOm1KNnyhQjRl7GhDnTpZ5AACH5BAUDAAAALEAACgAjACIAAAfhgAAN
SACEhQCHiYQrZY2Oj49oeoU+AwNKlpiXmQOInp+gnlpGhTAAEqipqhKhraGkSKaus7SesLK1uaCj
pbq+n7e/wpOxwr/Bxrm8xcm5yM20xLjQrs/UocvT16CwSi7brcRe4NikemS/DcZRVr9Sv5MhwhS+
S0YNIUy6+vS69gDyxJD7tERQPl0CAPTL9U/eQIIG9eXiV4+Uw4eICuKTWCvhwloNMXrSeHCiwooA
RWaMiPCkP4sqAZDkSMvjMQAxsOjCEkNKQZkrgRYsOEmQnqNIkyJVZ6QpIlIAoEaNSioQACH5BAUD
AAAALEAACgAjACIAAAfDgACCSABIhIaFh4QNgmiOj5CPaoIAXgBKl5hKmpgAMJSgoQARlHqip6ip
lFqmlaqvqayClrC1oa20trayrrq7lLm+r7zBwqq4xrDEycPAzKrLz6nI0qe8n9WiWoITTp3ZoK3g
48Yx5Ld6MTm6Sbqm6gK2FO7p67bttu858bXz+fXs3AGAJ4+euoD5Bu4r+O/gPYEE+xm0VwtfLX38
YPm7mM4WBF9LTEUBgKWkyZMmhVFgpEdPg5cwY8I01bKmzZstAQQCACH5BAUDAAAALEEACgAiACIA
AAeDgHoAg4SFhnpGaABqi2qOj44ANAATTkqGmJeFEQCcnp0BnIMTXi6Yp6iplKqsrROtsKivsbSE
s7W0t7iwurusvb6pwMGnw8SGxse2yqrJzM/NtXM01NRz09XX0KdhhEHbpwLg4+Tl5ufowWLn6+nl
7e7x8qjdAPWD9YIAevz9/v2+AgEAIfkEBQMAAAAsQgAKAB4AIQAAB0eAAIKDhIWDagCIhoYwjY6N
gl6LEQCUlgAwi5qbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8tWEAYUu/gr/BgQAh
+QQFAwAAACxCAAoAHQAhAAAHUIAAgoOEhQ2CaACJi4qKXgOCSpKTkoIwhYIBAJqcXpifoKGio6Sl
pqeoqaqrrK2ur7CxsrO0tba3pGK4u7y9vrgCtMG/q8PEx7BLAMrMy8uBACH5BAUDAAAALEEACgAi
ACIAAAdwgA0Ag4SFhgArg2gAi42Mj2oASIeUA4YBEQEAmpybhJMSlKKjlJOkp6emqKuHqqyvkrCy
rrKotLWkt7iiurutvrbAqcK5qy7EyIZkq8uIK8/Q0dDJlBSETNTZ2tvc3d7f4OHi4+Tl44IADerr
7Ou4gQAh+QQFAwAAACxAAAoAIwAiAAAHnYAAgoOEhYM0ZYmKi4uEPgADkZKTA4YAAZaWMJmcnYNU
g5ueo52ipKeCDYKmqK2srZ5Gq7Cwr7SZsgC2t5y7vIS5vr+FwsPBw8iCErCgAEi6ydHS0yFf08AA
IUzXhdrcgrLe34Li3OHb49no5urp7d/n7uXX8enz00YNIacCtzEAWQAKDEhQ4L5TYXIB0MOwocOG
g2RJBDDRiERZgQAAIfkEBQMAAAAsQAAKACMAIgAAB56AAE9jhIWGhwAAYIqMi46KYGWJk5NKAJaY
lJqblFRGiZaJA5ykpaanqJ2fl6mtk1R6Da6zAJ6gtKmwsri5q6G8pbrAqLasw6TCx8G+ypywzcu3
py68sl7Qm6sT2NyzEN2TU7vgiatf5ADi6OWJX2Lk6uvm7+Dx6PPw4+T49frg/N2mJPoGjseqLAAQ
KkzIUGGMWXpwfZoIgOKqVQACAQAh+QQFAwAAACw+AAoAJQAiAAAH/4ANE0hjAIaHiIZISGplYACP
kZCTYGU0DQBkVV1eA4ieoIZObmdaEYmoEVoYanoTm14Sh7KJA04XpaeoiKqsmbADnrsAMKO5w4e9
ra+cwchKt8fIAMq/zcK7xaSm09Sry8DYqNC43NPVmtfI2tLIyq7hz9Hm7t/WneKJ7PTD78z48srp
qucrHcBh+wb2+wZP3TBy7RYWjIfQGL9d/mBJoLXLlsBuAOxNGNPFCYxpXrrgMkOlGxWGAJ48IdON
jM0nK1aABKBHD4AoIbZYYdFtS4gySSiATCLlyc8tWHKAzPLmzJIr3a4sodBDTwyoOQQIQCaGqp2r
Wbd2jQJ27DSqGI/QTtNKoYYetlHdDiv7BopcZHTXttW7C+7fYXTt4g07ja9frHPV3h389k2cw7sS
T87bmGoYzKgCbw5LGBXVy5ABb1XctnNf0IlELxZbOW5qxKtHl07kGDYi2ZSRnfZ9SHMUHFG78f18
O7Nktm+wgMRCx85nkGGS0DTUIEqD7+DDfz9kBMCUFVPOp0c/BZHPQAAh+QQFAwAEACw2AAoALAAi
AAAH/4B6T0hjhYZVhoWISEhlZWCQkZKRZTR6l5iYSBddSkKfQgOgoUIwXRdmWgGrrK2rEWZQlpma
F05KEgO6u7sSpm5mVK7DAbCytLWdvMsDvqepxK7Gs8ibt8zLXl3AqtGs08iXm8rYu6ao3d7FsdS0
1krlu9rAwurrx+Hj8PED59D24PLZ2hdv3j91AatxIlju3Jl6CNmF0/OO3wCD6bwldLfQoj+IGiUK
dAIjV8FtB0NCWTFRn8dnGaNtzPROgs2bOJ3Rs3ePpcAuXmAIHUoUhpNTZ7REWMq06VIqsYxMFERm
gtWrWK2SeWLEyIqvYMOGlTo1RogtLNKqXZvWyhYPUu+SUJhLty5dKT3IIgvBIguEv4AD/2WCBU6Y
JQASK16c2MSSJGTCNeCbhYmAy5gzCyBsGDHjzzweT5lI2bJmzZwPf/5sIkyS0cgmW6l8GnVh1asX
h35Nuq/p2pdTe87d+HHk2CFm/wYunLji1rzDlQaOublzALuP05JNm7oY686hw97rm3rw28OJ7x6f
ifvy09/RX8cuund36uDVu2aPyb35+J3Nt559752WX267PSEZZQII5iATWRjGg4D1hRPDFlhkoeGG
HG7IAh0UHBbaiEuQGBoFUig4VQNRtOjiiy42oIcRU3RVI402dqWjXrQEAgAh+QQFAwAEACwvAAoA
LAAiAAAH/4B6E0hjVYaHiIZjSGVlYFCQkZKQYGU0epiZmE9jXU5CA6Gio0JOXWdmVAGrrK2rVGZg
RpqZnJ6juKESpqgRrr8BVGdgDbSbnU65ubypwK6wxMZ6tsnKo8y+zqzQxcacF9XWocyq2q+x3bTU
4qLY5q/D6Zrr7APk78Ho0vTs7u/c+8aAq2fvVLN/+rwhI+jPnLBoCm/Vu4cQorqFEw1mcxhL2jSM
/QyW4ygroCcJKFOqRNlQGzSP35zAmEmz5kwnbuqkisCzp0+eWoZ51NPgCRkyE5IqXTqBzBMjRlZI
nUqV6iyPDWJswcGiq9evXXFsKSMlCYWzaNOeTSKlhscoW9ywtIFAt65dujmwxFnCA4Dfv4D98ggj
5SqtBltYtBHAuLFjxm30hukbuPLgwtLgyn3MWUDkvZQrA75sWBNixZ0ff54sGvAV0pnjLk7d+DPf
1qMJl850ejZtz5JDt36tO/bm38BB4/4L21hv5MlZLyeO2Zhm37RtC2/d/HBi7KlXb69MfTem69C1
Lxdc3Pn39MHXlzcOvrP69d1pyYbwG8JqE+sBkB9vIVghVxZtIKhggglm8YYdYfDFg4QT8mAhX0tQ
IMVQDUTh4YcghhiFHlAZMcUUUJ2YIopQDRUIACH5BAUDAAQALCgACgAsACIAAAf/gE9IY1WFhoeG
Y0hlYFCOj5CPYGhGepaXlhNVXTBCnp+gQkpObmdaEQGpqqupWhhlmJiaXV4SA7e4uBJKXaWnrMAB
rrCxmZteucm3Er2mqMGqEcPFxrS2yrijF87Qq9PUs8jYuc2/3QHSr9R64dfj2tznwurgx+O4MKTx
59/F7fcDePl61i0dMX/2AA4oR7Bbv1j/7sEzV/ChrIQAGcqbdxDiMXfYJjYMZnBdOIULB260eGkW
DAkwY8q0pY+iQ3oIuziBwbOnTxheumzTQiWC0aNIjbpCs06PkSdkJkidSnUCmatGGqzYyrUr1wYN
mkYJscUKi7No057dEqJMEgpw9uPKjZtEypR1MXBgYQKhr9+/fbO8ObPkCoDDiBMDuLKEQg+8VvYK
mEy5sgAxgikUVswZQOPH1PLuFWO5tOA4mzsjZuwYsuTSlZkIDpNa9eHPePUygW1ZsJ3aqlmDLhYj
8m7ekzG/oW3Y9mLcoXUjpywYCvDOwl3nmC5G9vLrnaETlz5dgG/wirOHjryd+2z0idWPfz29OvzV
4mMVx9IeuXfrzTmXHyaiHVffGwA691xr6+0FAXIQKIfBfYgNeEkMW2CRRRscdughh1jQYQdtPJRo
4ok8LLFEEsMV00AUMMYQhYwzxggjjEZMUcMUPPboI49GVLJOIAAh+QQFAwAEACwgAAoALAAiAAAH
/4B6E0hjVYaHiIdjSGBgUI+QkZBgag16l5iXYxdOQp6foJ4wXRdmVAGoqaqoEVpQNJmZm05KEgO3
uLgSXl1upqvAARFmr7GYs0q5ygO7pGZawautxcZ6szDLyrylp9Gpw9TGyNm5o6XQ3qzEsNXX5Li8
vt3p0+zinMnvA9vP6erhsdzp4zfPGzh7AfHpG2Cun7961axxwjaw16+H6yKOq3jOn7CM7SYujHeR
Hsh7tPQ16/jQFUJZ+CTInElTwih5HiGG7OIFhs+fQGE4IXVGS4SjSJMepXLS2BMyE6JKnRqVzBMj
RlZo3cq1q6WIMUJsYUG2rFmyVrZ4kJKEgtu3cOfdJknSw0jEECyyQNjLt+9eJljghOEBoLDhw4VN
LEkyJeLYLAIiS54cGbDgJYgzA+CxuHE1vFnEUB5tebBmxIoZV2sAejTpwGEwnzbMWfXnvKJdSy7N
48rsxJ1Xt9a9G7bs37U9GwOdmzjv38Btx8ownLiA0sdnJ7+L2/p12L2hp1aeiXpe798vQ98c/HZo
78/Ft59e3bnx9dvdN9fN2/fv8Y6dBwFxEMT333yxhIADFm3I4eCDEMqRBRZ0ULAEDxhmqCGGS4SR
xBMRNRDFiDGUaOKJMYzYgBFTTFGDiy/WEKOMNWAVUSAAIfkEBQMABAAsGQAKACwAIgAAB/+ADUhj
VReGh4iGVWNlYFAYkJGSkFBlNHqYmZhkY11eQqChoqBOXWdmEQGqq6yqVGZgRpqZT1VdTgO5uru5
paeprcGvsbOYT524vMq+ZlTBwrCyxce3ysumqM+tw9KzE8jWvMzO2qvcxXq11eG6zMDlAefT4Oy9
2OTw8rPUyfXu8K6iofu2zt89gPEETrPVj90/gPo08atn7xS+chFp0TP4C2FGTAQbhhvnUeE+hhJS
qlyZ8mE+kxLHXHACo6bNmzC8OHFTp1mEn0CD/tRyBkwDdHoaTFjKtGlTMk+MrJhKtarVFUiTxthi
hYXXr2C94thSRkoSCmjTqkWbREoNpFHXtmBpA6Gu3bt122CJs4QHgL+AA//lEUZKN01x5wpYzLjx
4jZv4oTxK7gyYcPoErdxzFmAXr6UKwcmnASu3M2dG3+eLFrw5cOZNKdWzQJ069GFYWOSPfvxXta3
B+fOfLq3b9vBAZA2rbi3GMiSQ99+Tbx57899kysfXoz39d/SW1PvXtw49OzJl1dHPfs5eO3jZ3mf
jT286PiI5eYw7vl9eu7ybcFCFnLkYOCBCMqRxRt2hNEXDxBGKCEPS1CAGToNRBHDhhx22GEUDUxR
w4gklljiFLphEggAIfkEBQMABAAsEgAKAD4AIgAAB/+AT0hjF4WGh4ZVY2VgUBiPkJGPYGUZepeY
mZqbmkgXXUouQqOkpC5KTm5nWgGtrq+uWmdlnLW2l56gEgO8vb0SSl2qWhGwxgGyaLfLnZ8wvtC8
qBerxcevWhi0zNy5MLvRvcHD1tet2dvcy97h0MLV5rHaDRkZDfT3+fr3tt7g7dPgxYuQ7AEJHQh1
eFjIcOEHEQ8a1GLXTto7YvHOYUDzAAiRjyRC6jiI0MPDiBOd/QsXEGPGgkRCiiRZ8mQ9fZkoVhwn
MF42NCJ2ABnqMabRhRAfQIRoCZO/igNaljOXTESHDUKJEgFCAgjSpUofNMXlDGrUi1Ov/Qy69SNI
Ijr/iCwMC3asnqc7nVBzaY7gGTQkTryoMKSE4R8/LFi4GrOkSRH2JOoEiDYjMgxqbmjQ4OAACg4q
VIA4UWHEkMQ3OnhU+OFBxFxKJMieTXuX3lWWkZ1RY6HFEQ0HbIAWTdo06g1cdXxo/bpKFycwokuf
DsNLl71UImjfzl17NjWBBRNGnVo1EIQfTJ7Md+nJEzIT4sufH5/MFCMNVujfz5+/RA+JKXYDViTA
JZcHdIVlVxQhbGEFCxBGKCGEW4RQRhIUZKjhhhomIcUUHpTQRBOKddDBVl19laBdMViRBRMQxCjj
jDFm8cYZS1wBwI489gjAFUtQ0EOITQRoIopeeSAC/1hMZdIiFkwIIOWUVIrBhI1h5OjjlgAEOaSI
Rp7IVZJLruikFVBSqeaUNkKhJZc8AikkkWEiqWJdZ764ZpVXvpGljnDy6CWRJC4mZopKMinWmWnu
OWWfbgIaqJxDImYBiYwdlaiZmDwZpaMCWInlm4F2KaQOpp1mwYBA7EDEDgctt5wI63WK5qegCtAm
qXBSSoRoIIwwQqGrDrhBgSMlu5xYDbSoJ6ii+skrnF6SAMJoI5RwqYDGykSTSa41e2uuUu4qaa9e
inDDgDGJpBBrS8Ybr2uWeJprtH+WumOQUqjDjL3kmquvnP36e4uzuO6J77RcemnwweMG/EakA/P7
sEotCENw76jnUktBwRdvEgMOWLSRw8kop5xDG1i8YUcYPMQs88wyL5FEDyHXEkUUMfTs888+R9HA
FFPUUEMPSCfdg9FL32dEzpsEAgAh+QQFAwAEACwLAAoAcQAiAAAH/4ATY1UXhYaHhmMkYFAYjo+Q
j2BlRnqWl5iZmpucnZ6fn2MXTkJspS5sqKpsMF1uZlQBsrO0shFaUDSgu7y9vpuiTgMSA8XGxhJe
XRewtc4Bt7m/09TVl8HH2cXJy2Zaz7URZtLW5eaewUra2cqvseCz0brn9PV62OvIyszf8Lbj8+yV
a9Agg0GDDxIqVJihAad0+Yzta+YPGq6AAqc1eCDCAxEgOzZs6EDyhoWTHYB4ePBwVMRtE9/5E0cu
46+NH3QQ6XDDpIUmP0qUGDLiR8qVLZ2oe9nOW0WLNW32ytCRBJGQI30CLdGkAxEPIh4cbHjN5Utu
zGTCo4lRKiicHv90yNVBYkcHoEGHdCVC1yrfDw4tQWTaTS04eW57wY0rl8SGG0GHFk35EeQOEoDL
Cjs7sd9MgImnivjwwYNpHUA6/IxsYQMJupV1iAh8b9TSiE0NP5MH5IfvGxuAWE3Ns6cF4EAqjyS5
YQcREtCJfHz88/iG59Mhj6gwYkQJ3yNenFDBoTyIFyOGfP9hwesHsQ3wRUTrtCLbEwoUHEjBAcQJ
EBwcsF8KAtqgwgn/cYACCuWp4B933VVwAgc22MAgBwe+8AIIKByQ34cChuhACwwwUIQGDuiHQoYj
7PXeGF0II8GMNNYoQSvuPCXPCSkqkEKFC3rYY48HVBiigCkkicL/gxuikOSPFVpIXgoKOGDllT1+
eIQBBpyY3wErnlCBXu5lIEoXXsCg5ppswuDEMmdoEcGcdNY5JxUANYHeduKBQJ4NGPr3HwiEOuif
huKJOQR4GhZ10hAVaDiooAhOimCilzp6Uk87yNYQQU9MIOqopI5KxhNGrKDqqqy2uoJDJAj30Q1N
RMidUY/9QBSEi0q2XVFNWKDrDzcAQVdqFhDVHVfCCrUrd4uy5hpsQBg72yVRbLEFC9x26y23Vmzh
gRRJUGDuueiam0QSPRjhAXSx3jWEskNYsAOyyn7XhK8VRNrdri16ZVWuRJVwHGTO8tmvs4tSVtll
mVmybRsQVGzx/8UVM4EFHGHwAMDHIIf88RVLJDFFTsfelXAJNzinWgneBSssnwgSWimh6BG7ww6Q
zcseT74NBamGYwptVHIPY0bbtlkI4PTTUDutMcdLiGw1ACaUfHJjqe0rGcvJvexde2IPqoKhfpqX
83FNzNvEDUDnRRTR6vnscLUQ0xYCC1mIEfXfOWzc8dUiZ20yyvF6XXCxO1kAs8HO8fxDeJWeIOmk
6Kmnq15w0yp3eP3W3TDSeCt9CdN//z11GFUTDrLhW6fs+NfFdk1Uva4N7Ph2PvNL9L9EsddT0PNG
urDRd4NkuiV7t5F61IFz7LHrH8P+rlxEbOD4vN61LHl33ctqe/+97Qmbl60Qpsdes5L1yx3DR0tX
rXDXSsz381Cv3jr1sG+A68vKupVJhpaotU3OeFxpW7+2EymbWe5SC2Qgr4S2HYM1RyQkMdYDCKKH
vfUNf06L3uCohzWtVWBJL4CWUCJFtA2Rx0keQlKSipShCRHoSU8CFIVwaKDzVEBfCsxU0CSDO8xk
AHUgFID+SFhCk70gBSxijwIjeDkOEWhAKQiTpDhkoQY56IGEopCFHsSykSRLQucBVmTs9pUHNC+J
AhDh9PintR1wpWUk8ABpdFIt+VnGjLoSSlfutTMMnuQ4HQgO3gzZhLdBLCyliVcihRMdP+Zxg0gE
4RJJCLvQeJJtEx70GwjlyMROfvKUp7tfEjdJR5Oh8pVvTCIpOam1V6Iyk8+DwOrm6DqSudKWn/Rg
DoZJzGIOsw1YoAPreGCCZjrzmSbgQRh+CczQNCAKUYiBNrfJzW1GoQFGqEEPxknOcvagBjWYQiWq
6clAAAAh+QQFAwAyACwGAAoAhgAiAAAH/4BIF4OEhYZPZRiKi4yNK3qQkZKTlJWWl5iZmpuXF1wu
bKCioaQuaxMYAaqrrKwRapyxsrO0tXoXLgO6u7y6Ej6orcKrr7bGx8icuL3MA7/Bw8LFydTVycvN
vM+p0a3T1uDhyrnZu9vd3rDi67YNGSIeOvIfGZ3k5c7A3Oiq3w3/ADM8GChCxAN2CB8A+XEixQEb
J0qQaGAJG75z/PqpyaDjxggQKDhUGEKywosTFW58QChOxI4SIA60cJAi4sSK98phzPhKxIYhMR0c
AHHiRYUTHFCc+HGTZbUMJCy8UOFQxYgORHQYLFgvkkWd+jL2Q+PhRgUOCmiirDDiJIgXFv9WOq0m
AkgJtxU66PDQYUgFth3kQvqabSe/CGhIlGioQW2JDh4+SPbwgOJcah92DDl5YsQGHXY55xUhiXAz
w+gQ7/io4IgDiCWIWL4crm4JkyeGEPmgw0LbzhsOes1ZOKzYCGU6VFCR9oCKzjeIkCAChAQ9PQ0+
EPF9AmUTrCSmb7hhocOGDjt0fPCw4cfRF0NukBCuJ4OHHe6LDtF7sIEIIh51V8EPO3ggQmZA2ZBC
ChwUNRUKCqIA124HmcYMat0gZ8FyCihgA1F/jXDUWzdEtgFrBSyAwGsqEPUCCGkJhYIKRrVlgwYI
EICABgdERMQDH3QwAnMGEKDWD7v9BGP/EQQQUIACHBj1F1oFGGAAAzkiwICVDDwJURM6NOCJBGSW
aSaZLviAxD6HlfHDCxwc4JyAI/h1UgUWnDekAi0UUEALUIJA1AkoOOAnjzaEpMKNfjYqFAgj/GAB
UAdo0MIMUL5QggUeMddno0d4iMKMVPp5pZZWVvmkUmA2UIUSMMQq66yxKuHEBFBEoOuuvPJKhZtw
JtodSnXiNtIPQ5xgwwFRxgcEEUKeZEOHzhmFFAopQFRnsthy4KJbuVlAggfsIUsogy+McBsICjaY
7lRJQWquCvGOsMMHItTzxAT89uuvv2Rgt8LABBdscAabcdCiaMWeJGUFILQ4BBBd6fEA/xEM0QtC
CUB4gPGLNKqUnZAngMCBwkWhFBgkDZQ1Ym4UX/ymoEaVdNLEH5DQBG6e0adHCCwELfTQQ1sRhRQU
JK300kxPkOy3dNpZsoMlpySYxQu5Bdde0XY3cT0K3YVUoi0q7BlpGXxcMlweYOfysFJy5pkOGBvb
AWmR4JAGBHz37XffX4RAAQCEF2644SZIMUJRfzEstaApA+ezQu7dCVlHuC1108U7l6xwxAc86hkR
L+G1cnYngmuU3J/VbTnekFgBgQC012477WIEIfjhvBeeeFvq/kas1C1Gbu/kC9kdz4bDMkXRA1Ed
1Z2UzBWgQQpvNd7dVaShvtnUL4S/ff/rlasMux6y364+7boP3jvvvw8hqfBsEe/i+MiXn9fyLztv
MRGde4sFniUVGziAJorqDgjyshLUCY9xrKOb/u4mifSt73btex/8yjCE73RteLiBnOmuRjm7rccs
w/oa1sS2QJVYLCpwwpYNbPCcFjaQL8KL2/gkaLfzWfCCtcugBhEnhR9g5YP1yxxKQLYU2URCZib8
wIlKtkAKBmlxgjoeJKCys6nY4HNEiY07dKY1tgjPXjx8XQVnB8Qg7m6IvpNCdHSAxIYxbggfWRCk
LLADEujgJ+F7HfSaACd0/YA8yzmZAMNDOkBSkSgg+dAIOLUYRarLAmLrTIE+FjEQTKz/MhT5YRuF
CEcAJO5eV3ScsZpAnhcUqgVHaAGPWgS10ejBJZSy1Ax2OQO1JJE5jXGAhzojv7Pw6Qi81ACU8LQD
R2qSNxtCC6ZUkBIPNECUQCQlHE2AhPkE6WU10poF5LGhQiFARSy6H4nkYpuYtIAAKrreUjawgSY0
ZAYJIMAMhjICIJzwLA5gwAIIUIRlBkaKi6tacHDpztecoFXYvKA2h2iCHlTmAR47zwaA8CwgnKdj
F6VjshZmRI56tAMdq1h2tgOxBo1APiHtywlIei/LYHQDi1EBjUqwgQ9QJAPaaSZWfGoxkd6pCUQg
TUTXN1ENVpQ2UEXGUtXX1Pc9NapYYqXFVDH4xlJeNatg3QQO2NhGAVS1d18Nq1otsVXbBc59pbxC
D9ZK10rggAlMyIFe96rXvOaACW2IQRJMQNjCGtawPKhBXRcbiSiE4LGQjWxkY6CHKfTgspjNbGZr
YATGMjYQACH5BAUDAAAALAUACgCOACIAAAf/gACCg4SFghkAZ4aGikaLj5CRkpOUlZaPDYJsAJud
nJ9cl6KjpKWmoqGnqqusra6vsLGys7S1tre4ubB6vL29AA0fOx1AIpm6g8e+yw0ZGQ3HGR5EH8fI
lsu+DToVCgYIByUP1wBxQyLZvCJNKA4ONuciQwozHBvW5JHpvycaBP8Khoy79kPFjn1EAMxAgEBB
hQ8k+jE4IDCfpH28HpQ4YODdCwskMjzQQUJEriHhHmTLYCFFgZcOP3wYoaAIig74LBrCqEfHCwcz
VADRA+BBSwcggJx08EJHNg8VHBiA+bAokA46cuosxDOiBqZOAUAFCiIhriFHOODU1oHDjLct/2Ju
xYbRw4uvD4mKoKnhhI5ccY4oGIGu14d5DhQcmOFQRAYdFn5sKMwrA5AKKlBwqLDjQQYSkYFMG/Hi
hspgFk5wQHHiR9ZlIm6cQMHawgdfGYiMyKziRQeVej50eJFihoYUFUqUqIBCw4wDL0p0qFbLjgIN
ZX0BAaHhAAcOgiuIMOmggD1eDZT6W7AggQEbN7g5aJGCgwICfXWI2FiAAHsCBQAwwm16NLCBCke0
lwABB/yQQYHbrecfAfVs8MANNgDAwEsG/PPPhgV8w0AKFmglyQSX2IFCESk08aAeDzRxAFKYxSWe
PAoZVOAGHLSAwFQzHEHfDR7Q1IJzBizQ1/8NNCGwYQtHFMAAAzHpsd0MBszgzgwpOGigCj4aUMQR
RXzTAgpNWIBCgAAEyBABP74kZQEkZnIBJTAIgoElPn31gge8+JTYCE2AEN548wR1kFcMOKDCDR/o
0EQJO+hA01QOcADAD01UkEKWKZSggw4lpNACnU18IGMBFH3wABA3APHYT1QCsIEHG5zgDVJYleCW
Bhz8AMAOhQIFT6UPmBiJso9odEBaHRTYQXMc3NABggoAgCg9BsXokgIvEOjLTN5kS6BdGrSgVi8N
YFgAUx2UoIC6GyzDkg0FgCvuB1HRWSK6TN0GALl9kUAIs6uQsQOCFD2wlwJgLWzjtoqOBW3/Oh8A
MC8KNzQgLQdFVNmLoEFNesC7ABDxC7lndtxLBjesOZgIXjEFqFjdYGfWIFbMUgO5DpxARIQHNPGA
xI09HNQGRPQTtFPZZMztQXrcy6pA4xqJggUdgNACAyGfAEQmgmI3FLs7GGpzzU0RBdV1ZS0iRiw1
wIxCC/CgpPOXhyqtwgZAnKDlnxjzlVRGTbjU5YvqzIO3adP6iEC+A/ap8zJXgsX2zWPpnEsPPf2k
gA3tZKvSgX0n+nfgg0O9DMGHw9gSq+L4Is/GLh92wNcGDDacA5ejDcLgHmzuds5x4wL6Az/sfsRb
akGDetKqb0DCXWYXDvfZducr3i9jKZr1/8nY/dCNutGy21bIhBmPM9w72wJ6A2lj+S7hfGc7Hk2K
kks5cOPSmAYAcDYCDk8DOuKFrUBmM9jwTwVNaB7lKPMwf33GaYTDGfCS8jlekEtMi9sRmJL2wB18
6VTZIsEDPnCDH4jGcGfTw+06ooLfiOBaGiiCDWzTgSH8Zhs/wc4OruQ9HTygSCd7mh6MFxyaXM1V
A6EF6KoWswJkT4QT89tBmHeyDX3FOfAp0vZ8EREHTE5LQJHSzB4WFwUo4Ai9I4xRXIKAInyxCAiA
lseY6C0gOeoGiJDiyPrRGPS0pVEP2Ut5ziM7l/yjPQUIY1SKIJRlCOqR7LkaOkyigAR4cqFB4AIU
jDBUBEzixyAe00PTjuSXX9xlQi0KpM9eRgJOvaZALKzAEGSVm+VAil0fKEgKvMOZB7xqCCOYzkou
g4IDpEAFJfBAKhvgAQuAYJgoqICslgEAa2LTNwDU1gZGMAILjasgB0DBCLJSixrM5Z1bcSc853kN
edLznjzzGT73ibBCBOESJrDnPvGZA0tcYRIHncJAFyqJGADjEkRhKDwDAQAh+QQFAwAAACwmAA8A
cAAXAAAH/4ARanqEhYaHiImKi4yNjo+IHjcWQA2KghmZlo2ZmoU7HZuQo6SlhiIqLQQLGh+XcQoO
Cgo7jBWysrV6L6sqoqbAwYgPBwsGBAkzrokRJQwIDAsgiyIKBM8GHXoP1gwzHsLh4hUEBQUqJSMi
ehkbuoQRP+YFBg7LiD8G80XaDSALCWxkEEfQVIMUCBBwMDTCwYIThiLE0WeOQYlEDWyUM8ePUAYL
Px4UHDmKGwMGQwzZWEAAYqFmBYo4KIIgxS9CQI7UmxFTG8mfpBooYGCgiSEOCAi8iDixyAkHDI4A
QXSCgFMH+nwCGTJkw6EGHU6gSMGhgg5CG7gS0bPhBIi1hP8+DFFhwwaIJiIPPSjBIYXdG78abHjB
wQaHF3D1fEjnwBy6EpAVGDCQAjJgmAV+gCDQ8tAHBwQUdMBawCcIGTJQGCJygPOqBTIOWEIhIwGI
CgwSJBihp8GLGa9dO7hhCIg1gAlkOFhHiMQBBAuirzq3rgPnmAUYuN5ID5mCBxInW9iQXQFzQkO0
v/CgISuhqgRUFCKioZxVBzMSKBioopyCFiwlkNJmBiBQgAZHlINAEcQpBloBR8SCwHKEEAHaMUdo
UEA5C6TQjnbzFOjaPAUgoN8DVJRAjwVCGWgUIQ20NgMJ7DFQ2nucLbRNazGdoMMDcqkwEAflMNDC
CRZUsEP/EwYyYMMOH3gwRHsImKfHCATUU0k7L6xDTJYzjODBB0BwYCMBFWSwww2SFXACEDvssMEB
BjDAgZxENLDCDUT9oAc5BKCwyQaqpKCHDhow0JEeJySlYwkGFnCRIQ1Y0p85fnr0HAMeGnJDC9ml
VFVNiVhAUaYwogDNd70pgIABqOqBlFKGJGEqrHqwh4AGJBBCoJ+IGrBoo/ERgsI1NinSHwOyFZKT
OQ0WclBCC2FZQAsV5FXIZsze1AE9LXjFzauTEjKrS4TwUMdkmfaHQAUOhrYOCe0Nm5B8JjHAm7Kc
yVdIE9lpAM4ho8rGnn0OVLDMtAhMc4gHWOE6rgHlypoQ/7p6qMsuId9W2cAQFxMSrL0ELPRZn4v0
11khJdRpDyK8IHDAQKNdo50DFrDzHAJLeQYVStu4SvFRIReiMa46E9DCDykQIJXIiZJs8s8p8YsA
xi3Xc08hBW/ywQsPInBEns+tbMjJEgtd8bmGHI3qCAY6UOgm9CrqE3zyZVC2v4kQebUh3xoQ7lca
FWvIAy+A2hmRTiJCqOBTTbx2Qj2nuy7SuZKWXbn0Cnt3vzgWMMM7MJpLwN+FnIwA3zjNUKefN6ms
GtwQemUICAmxKjnRDbd9eawgKKp1IYjajWPJFbpezw8iNCCCZkOejjGjG53gQQYPdDBUlSJVYL0l
IqSgHf9EaOP8QANfm0PAvrtvm6UCRGTwQQNuG7JBESVi3LnUhcA92YQK0IB+ooe6QhBjARuaQSyy
Q4AZ2O4EMojQARpjpKnoQR5EqUcAX7UAFAwkaOQyRAnKYYAZOOAAD1AXQCqmNxkUwILNKUICCGAa
1KimEFNiCTJ00yzayMBhZ1MVZ6LDEgXYjlEyQE4CFjCDWDXBIatYIgJBoC1u1KZqhCDGDAkgg+/w
wA4VqECvDLGDF5TgFyIYQRiX0YEXvCBacamADQ5wABRUYGA3cKNPHHeCFNBRBXg52wg4QEcb3BER
IhgCIQ9gA8QcIgMlCOMYDVgBP6ZgCA0wwRSAwslOBiMBEAAh+QQFAwAAACwFAAoAkgAhAAAH/4AA
goOEhYZnAIiKiYaNjo+QkZKTlJWVLgCYlpucnZ6foKGio6SlpqeoqaqrrK2ur7Cxso56DUAWNx+z
grUAGRkNkL2+wQB6Ijc6u6N6eh0KBgQJILs0OgoOAA4cxYZ6DweC2w16HwoJLR3LoM03BQAMBDIq
1SQFBAwIBTuNzT/4DBYcIGeBQIEE9NZ5+qbAYLYhFpp9sCDiFQ0SLQAUuHeiX4MUBDQiCKfHg4ME
DJoo7NRsx8YC6ox9QHGkABGLGAUVMOCgIqFmQDKKHNjMwxB+Kzk1swCvJy8i92aQwNnCgAYNBRj8
KNQMBIEWDgqM7JZ0oZ4b8BRk4OVhBoMZHv+oIlAAIl4KssccEKBrYKyeDE2GlNDFq9wQFTZsgGjy
4NuPEiUePBih4sXali842ODwAghXPSReAEjBoULcwiJKgEisokTFlqo1ahghqMSLFgVavCgxZOqq
iy3mbtDA4IhvY3qGECBQoQIBvx80JCAQs9kIDQCWL1iQYIgeHQcLWAiXQIOI7ynibc9ugIPPWi8K
LACQIIEM0civa89OQMOPZhzIgIBG7wiyHIHLyVABK8DN9QAHy+FnTAMHEACXc36J4AADMCH3AgEG
5KNBWDKM8J0GBsygQHblPWBSSF9hZ5BAjSUHogEAKKCBDB0182FfVs2AQIgIlKAHBygROCD/AAgw
oFM+CSxIiRKcNKhWB30p8AByG9xjgx4fZrghTM1gKZYCTIlARGsnbrRXCT+8IAJIuS2opgoG3PNC
LQc0CUJjHwzxnzMbMXBABx980IQDIWrggQc7iMYTUzvsUMIRBrRQwg4bEFaJHpboQURwWmagwJBo
NaMCPhGFSZSGHHbAJz4KeNoMOTpgx4ACrzmTpwElDALgkA5IxigCTP3UgA20bokcEDPo2U5azn7n
1gzKtEKBEaM6qIdzBHAgkwZ7NeYqObCSiVGIKnmTazRDFHYCrd209NIGDZxqgAJI8RJdX/EKe+Rz
RDHFgFPGkHDtcQCwkIoJU2DkrQcaIOCo/x4jIEDACT4SjO6Ysqpklac/vVvABoXZoHFCwn5wrJEV
LJBVASmkqodLmXomsHO7GmMwwqC5ZZwhApwCscRaArjcCPl+RUTHYsaKcZNa9qPDDJneNGGfG3P1
gALxmJgBNQYtZ8N57qSYbWFDNNmTHj+/p/BbDKtyNKk1diDWAU3ccxfUr4KcnNs+cXV11rxQqDE1
P2kYYrDNbGCDTgnY0IDeBhyhdWEj0OpzU3Iv7MrdDhpjKgJHhKWVhx7nJfUNee5jNdYtaK30WAKP
mifKhRFxQJ5F6OBBTQwkW9iqCPwdNy9zSzV6xHjnN2BWxbIeNZku92W5sADgSrvtNhZQRP9MyIFA
9QN4tbVRB/nmc5ewJt1TwVKgM491ETqzQnrVxlCsUdfWC5zU9HACmSEABUT4hQ5O8J/D1U5YGiIW
UxrwgfjI7xgcsEDeqlKEp3UuKxzQwS+AcAAGHOwD9DvYe6KTlT89oHCo2F+19LCq3IDvXK7r0DcO
IDODKEABLSjRiRjwwMIwZUhO0hEADLAAG2TgGORywAEOUJMF/C0DNkjAPVrww6zogykpBBqFDMKT
2awCYkRAgAyqxyV5DEReMpCBAtAlnQVURwQoGBAB5sMd74AnAQjIH3IskI2QJGA7BfiTMTQ0iEMS
4ACE+QaeDgSA7TggWc1QSXneQ6gF7FF0QWesQUVeMIS1JG4InRHYBl7wgh+QIwNDaM5puASCFBwg
BSCwwBMn0xyS8SI14rrlCzZXiw2cwAZTVIEF8KIHIJzAlgfgQGQEpowKlFJgQFDBFDmwuVTUoCzg
DKc4x0nOcprznOgUBajSyc52AoAM7gxnIAAAIfkEBQMAAAAsBQAKAJQAIgAAB/+AAGMAhIWGh4iJ
AGeKjY6PkJGSk5SKeoQubIYumJWen6ChoqOkpaanqKmqq6ytrq+wsbKztKh6ejoAFkS1hnoNhBnA
jbfBGYS/GxvDvaN6HyhFBAkOD71qvxwOCtsklnon292/IAsLJ8zNn3oiCgsG0xrWtdgNBwsMDAkn
lh8aBAwQFCCi54GGgPLUgbp1YkGBIidKjHhQsAMQWfUOIABQgIGCeb70jCDAsUALgg04JEigIp3C
SXoyKEBAAAQyPS8cJHiB8ZfGkgwsIPK5sYBJXjF/NDn20hM7BwGFArh1j0CFnvYQtHBQgACKoR2M
OjhytCmpmFAZdLiZguYIrAf/CLR4cXCGh5Aq5NI1cPLWhiFDLhaKeYNfCg4jPNzqAJiEnhsgQOSa
6mGEChsoQFhgOljEEA4pUJxYO7hBhxMobHCo4G3qB4kajNoEUKKEAgMMUJQYcuNVRgIFOqAgYNWX
h38HNrTgS1APChkyZk8FooAQyQUyUlCF/uLFtAQWYp5ocR0AcQUbbnZwYA5AAhkKmOqhbh7AAvsF
QFC0kIAkx43WEdLRNAe4lMpvBgBhAQIIxHdTBcSNoEMRzN2SFwH8TKUccHKNJcMBt6QAnAJdTWNB
Sg4Bp8ERHLawA2X/GDADNwQ4qMcOLJp3RGwCJYBCAzf0J2BAxPlXgAEIJFDg/ys+EWDABhlAFRwy
MhEwwwckUNiXHhfyU5ACwLVQgQ4PeFABCCECh8AML1jwAhFDqMkBECJURlaNFHlngAI6VPRCBl86
qcEQHnywgw0CEVDCAztYoIEBBrxw0Q4bKJAPCEBs0JorTRrQATjEqYBMbwRwoAcRWjanAk0n3DKS
UVIh00CaD5H2JQNe+fLDf+FdyMEht5QA3JRUatTgrA+kZasebRHwliydfkpCCwxo8MEtwxlww3yp
Wkhcq/YQ9+tQzJqXwmAbGFXAi6VZWhNOwB0xBGfYEoDAub4IZZJjIqQlFVU0XRVLDdHeYgNxQ+DC
YnzcVsjlt08huSu5ImI42P8QABjggAghcUCcDacWYZ0CFVgTk7s8+TLtkZ/2m8+/emhU3MDRTrUg
ASB6V1zDW66KoR4ezAApacAyG/CDAHgE0lR62IQAiHo0ocE7DCzgwAa3OgvscbiF53JQN8ksMCwE
h+vpVA/M1MINYNo1XbcP/8w12BQTJ7CrGVeD18fIfHDCP11p4EED7o6NjA5HGBDcUy+HfTTNZq91
i3cFOEDeV2873GVBUFlc98w2c9TCplNl5TkyIvDTVQUx0zTuYDcwUMARfX4Ns9iylB3X2VPpMEPG
HfWWec8Q6+FxARqQ/kuaoAM9Q1fSTRVWR2sxwzyalM+wKbbmFcg43QATkDL/2TUzjQICRSiNDBBw
dznVix05YMEDDXiGJrN2D/awUS980MADN3AAPA4AqO58YCrtwNULcCE0j3SAfn5THAGagEB/3SRb
CvBABvznCt05iWh6sIDsxDcY9mnuW0zTE262oQElMc9wzwBT4LiRMQJoQFUy+N0BuIIA2t0iTrjR
mAJm4KQFtKSCjWNaBRxiAAA4IAUGQkXZFCCDBAhvKjKRQQEmM51pEAAI2ILObG5RgRYsgDgJAEB2
tiOD8SHDA+ciDiHOqACkcEkG91nJAjQgvGBNjSRpdAg6UNdC8HRGAf0hAHyiaIsG/OAFFbiLel4w
sb5V4JIiuMUNukM0ylTAVwYHOAAKRnCtqHWHXb4wjU1CqYLN3KQyvzqADSpwQF98YARfkeULuIjF
EVySl+zgyQFSUAKzGPOYyEymMpfJzGY685nQjKY0ITGFaVqzECGYyjW3CYBAAAAh+QQFAwAAACwI
AAsAkgAhAAAH/4BsLgCEAGyEh4WKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqeoqaqri3of
HRY7DayKerMAGbePeoW5AHp6QB0ZtKJ6DyAtBAQtHsW/eicOCgAOHbtD09UbwCMECSi6z5t6GSkJ
Bt8MOs/AKAkADAkcjuUKBAwMBDe29wUFzsZx0jNkwT8VPyp8sLXjmipgHAgA+DfjQyM9HQwQKsCA
n54XABIcICZQEzAbABCgJKSnhIMFKlZBlDiRwAhGMzd2/NXAQokHJck1OACAQIVCejgkIABCZlIC
RRwUQHBA3C8dRww40MDxRlBQwA4gIDAEaVOmTiMWkGagwIZWL/8IrJW6Uw8RAEMcsmyw4QSKFBwq
kPi1A+8OPTtOqADC8kMJFTZQgPgBtFaGHypS2ABhQRewHS842ODwgvGvByWyGWDA4QehEkQZHChR
ovOpmQR+nCjaFOmDew6AOFjtNRoAGSmQ6hBbFMCCBAoy6IkpQ8UQBgtkVOg2Y9mCO0UdWEBK4t6C
kAlmiGDpIYU+58sMoBBht/lEBoVoFkiXwEHlUrj9QARHDqzHkgVjnSCCBsT9AhIBK+mhgwNyQeXA
DP1JB4JcChyxAAHaRUOAAQgYoEF3qzHQxGn+tKCAAwwcsZ4eHlBYADNcybXASCS8NxGJhCCw0VQL
+FeKGtBERED/CXqItSRLeqQgFxEPMFjXgyjZcoBca5HwgGMoPKDHhhytZUEFHXSAwFQHbPDBBz8M
x4AGCzUhlwayZACEgrZIWUARFXggAhEqMFDAAi800BA1CIDA2A47pICASjtsQIRVxjxFFkFFVfUL
CUUQcIArVhaH5S83SMTATUg10MCYcjFQFjSxRYfUDi3cOIIeR8mG0wYayYrUUybS1+RYs/4SE1oP
aTqEHgsyUMRdIm76QakOFmUDMDHJhukvTTGgwC00zpDSisPaMNa2P3D5wn+/nIDPuLUwxlEHWo7F
qrK8pbVMWWMWdcIxDiBAJ6kNfpTStg1QQwBIF52FAlLXGNAC/zu1gCRuAyLYSIADL1h0UlH01NJx
Uc8OpS9Sy/aWCm4AAzGVAw2siBbCV2pLsD7JtnJWTCw1USKdrVQwr5g7vASAAQto0ERYY7nM0m/p
7KqyTSz326ySAA+FTxM2yFUYzqbq/IADRR0VcVFA/4JgATMEhJTG9B5TgY2GHpYcAW1PPdymV+87
ndYvO8tSCXI5cARVs5CdLYT5EjDx2nwjZS8DekEzseS1PFBBrnwPzngtoO7HTeBZM1s4135vhPUv
1yZ86kdyFZE5L6/+7JsC+qzEkg4z3JhyLWeloEe7/9y+GwP+RS74siWv/i9S8hZhokWwY6swhL94
MIMBJpYgQv8DD1iggpi6I1XBeQyo4EEGGezAOwIF6jECCDq8+oC6oZ89tAUP4NhRDnUU51HvTkDI
wAe+BRbDsYQIRbhR2xy3vQj9AAGGIoAGXlQkDbHNMikwCAGOoAAFcGRN1/iIDFx0AKms5i16uMFU
4jENDaxpASkghgEPxKUjTANeoziJDGQguCjJgAB6cUUREpCA8RhHBkRhyQ80cB6JMDE6g5NB9KbG
AfzQ5EPWYEkFZHCekCygBcmKIdoI8BznGOB8e1HAENX2iwzYAB4g0gAQM3WDF7zgLkghwguG4JkH
3CRQhAHAC8aDlA+MYGIHsEEF2IERRXqlFcE4QXIO0Jr/uGJBCPQ4QApegDHflCCUKTiBafZSAj+u
8jQjSIEoK8DAr9jylrjMpS53ycte+vKXwAymMDFBhmEacxExAEAtjznMQAAAIfkEBQMAAAAsJwAP
AHQAHAAAB/+AAIKDhIWGh4iJiouMjYt6HzcWQA2MepUAGZiJeoOagno7HZuOpaanoA8qLQgEMx+W
IA4ACg4bnCOzAA47AHoVBAkcpKjFxoR6GQcJBcEFsI82CQYMCSqIyQoEAK0dl9oAz8fj43ojC+Eq
PxUiyRu3h3oo2wAGGtCFehYIggUMHb5OAEiQIgO5g6j0pCBAAMUgcw4SgMA2rx+BIfFs0PMH8JKF
Eg8QinT0rdWIh9IICIw3r4iDAggOENNDoogBBzM4jtx5So+CVj8ecgCgkiKBAiccGCgAJN+Joy+U
/vPVdAjAhw06nECRAkUFHb5uDQGiZ8MJFU19fRiiwoYNED//QiJ7UEJFircWSJV9wcEGihdp9Ygo
MeQlAw5BAZQ4AIBBCsV5kTkk0GQigYkPHzggoACIBmodBcp4DIoEY6IAFiRQ0EDPUBkgRiBYIONk
gwozBKEj6sDCQyIKUgtKoEGuHh0H+AlfYIBDu14bGQzaaCCYA4MPJ0+i5kCur6AqRcwAHZCoQ18k
NBwl4HLG6tYqjiposYBAbT0gmCOwd4SAgXq+CbZZAS3UwsAMIR2nXjMtaNBMAQkckEFT1PFDgHLh
IJDAdZIR9YNPQA3SwEIFkCAeeXoI1JAvymyDlA4PfFACBxnoEZ8/RZxgQQUb3HAUAin0IuNnDDjQ
Tgn+OUBJ/wY7nPDAJQcc1UIFHohABAcIFLDAC0x2oBQCJ6S1A2MIoADEBkToNdmHJxFAmh5ENHMA
JONNlaJ5vjRxFAMYPQQAfHuWIGKUMWHnC0DNjKDHCxeehkwHWSIgaHZJJvgTAZP6MlRRLHkIiQYM
FEGCL5aVoIcHdYaGp2uNYhMfA6yBokMLMPmGTAqtoKDHEC5W4B2pBMCqVy8FGLBBSRcJRdRKhsjj
oS/XEPCCYBogYOSpqQZ0oa4NKMAAARW4StRQoNyQ5REeOBUsax8sSIADL0CjEFHXINNudaZ220qf
mi5L0bOhwMSaoJf5giqKKuqqGb7iFgzKD/7dkw8wsNboJf861WngWwPJcZqZUgQoqm+yoGzKbD5r
+sLxfhaQ2BS2CJunh2bfnhRPtJjlGTE+oDyFQKyCRbVnAUTo0XHOoIjwGQEfjsyva/52yjQovBbg
QAsEyGRwtnc2hCy5zeL8ELHG5mPDuHNVUISWILAaUz5EhFPADsg+bfK/U/uitAFLkQyznQlrW0AR
vRQCH1E5zwzyeaXRiuklyESbwq4uwgMKCMF2V7eyBNTbbMqXs2ePCKAcDPiqs9ajwQ8iNPBAEyrU
KPZDLzDDAAjpPrCBtz8/WcEJHrT2AK6XCbhfbw80IMIL4SwQ7uahW01EBh+o+SwoTTWTuOmqrugL
r3wjoEHkLe/ZiPhcyzSTm2FZ3pKiDEcocMBLfPeiDzXcKbBgAjYYBP132zDAERygAEP54jEy4Nef
DiADAhTOYAUYyA3KM5qHlEAD6KBH+V7juaShwELTUQA8FiWD3SRgAS3IlD4cUB/VEMUAKjBOBmZR
m4dkIAUJIIoMOPQQ37xgVA8BwguGsImZnYRKYQHAC2wFig+M4GwH8Eq69DDBF1wlH016zAHU4R1I
jGAoB7DBC9KFDBEMAYwpOEHcsCKoF6wxFRVIwQFSMAJi8OSOeMyjHvfIxz768Y+ADKQgB0lIPk6h
kIgUSSAAACH5BAUDAAAALAUACgCWABsAAAf/gABIAISFhodPABiKjIuOiouHkpOUlZaXmJmam5IN
hkJsQgCipJymp6ipqquHLqyvsLGys7S1tre4ubq7vL2+v6Z6OjcWJMCSep4AGcqVeoUZhZ47x7F6
HikFAAkKzdUNKQ6ECh/OIA4KAOQADSoABC/VrHofDgsFBAkO0fLsCgQAGCSoQOlaCwIMABTwQK+F
AQQOvPXjpAdEAgAtTpQY0UDPgw5EjjVQkLAAgm6T9LwAqPCIB3YptoGYmOqBAwbwpJ1wkGCESJKE
CjDYMCkD0JYvPQKwIJFmJnoaDDDoIC0dgSE/EbRwgM/dIT0WCBRw0KKAS6evHkQ1AKSQHgUI/wj8
yDrjhUMNIr7aIFC37Fk9VIeEdJvBAggbKVSMKKfnBoAhOsCCAFEOgLAKHACgAHGDn1sRIzikQHGC
mqEMN06gsMGhgg5C1wBUOFKgwIlCQxxIzTyEaq+RCArsOBAXq1sdRQik2FD7b0wZt2F3SPcOwAIZ
md8mkFHh9oIEHTyCwGedEAEFgy3f0FAegAzqljf8A7iAwL0THYfIYGmyEH+cMsT0G1wF6FACAQgc
0IwetxHQREhmJWXDO/FY1oFJ+BxBlgwT6kFcAUDlswE4CeBTgAYH4TNDSHqQ0AICBsyggD3UAYaP
AXxFFVwCKuhRQgIIBMVAkAgW8lACAvICXP8BRKhlAJOw2USABg9QE6FlE+YEFYxHjODBAx68MJOH
wU1ZgQUv6FBBiQioQIQIHlRQBD4KMrgAAwow9MANL3QkggMIMKDBDx98sMGHBFjwwAYWzFDbCG0B
IN9DJwCxgTEDBgdERe9Ep8dcBICgB1FX6pFlPCrdUwRRbhHSwIctmKaHCFERkJlbI4iFwAZ6oEBA
qMjkWkARkRLyAEkEHGDsWsW+FddcwCy5KRBCOfCAZcqyNSpSWFLoD04zTfJqXCi4dYNYRWAKjW7w
VATQDCV4o0cK5H41hFgzfACVAQaw6k9xhlihJIFtjeugHkTQ2RGpf+3V7geOIuCYuMQRQBD/bBUQ
YIACnsHmMAd67MDAk+eNwI9NOPpkiB7U1rbpB2v5C9xVWRXQlo+/psDgO1htW+qpLc5pMyUGq2zZ
CQihtDIHv3ZYQgsLBLSAApvSiiO0x8051L79VgVwtARb9icDM3QAKF7xcWsqhUEL5VsnFRutUtId
Y/nrrdeAoIFYBDggQgbsGudWwi5zLTNcNIOtKWwgiOVAcl753DDbtOJTIdxxyX1gAfkeMhJOl1v2
AQhPLjDEW++E61YT7+oLM7+Hx1VCzZEiXNuTQ8HGsITezquxA5XB5mrcWVu+sgUMFKCtvBWf4C4A
GgSPbVwxGe41AUb7Iq00xBVxkjKS865l/we6KtDBAw2AdhuZ2K+Mwj0FVCBCAw9YUGsKHYFQAWMf
KGDAAiOwnUkUsAP0eUAFZXKM9WBzgKR9IAPS08X2YPMDvsltd93KydFKxAAGoEMDHJpe+9xSD75p
YEYAwJEDJCQD9hxAA/iInmUqEDWFoGMGGkuAp17XNdicoEQG0IADJvQbcSTANJZRiwxaEDzAEIIB
SVEWdKTxggJEjT7YsUw6ZJA9y+hAWe9IwBUP8BosyaCGYtSAv/QwAqjZR4wLKEKfYPOBAiQAPCTk
yTtkAEYlYWV/K+NTE1ZWmQpcCywAeIG/vPiCmByAA4uxzFxekB5DNMAwhDgAZxakpnIdABoFI8jL
yuI0oQPYwDUre8AIKgBIEt7GlE0IBAAh+QQFAwAAACwGAAoAlgAiAAAH/4AAgoOEhYaHhQ2Ii4yN
jo+QkZKMLmwuAJeZk4U0m56foKGio4KdpKeoqaqPpquur7CgrbG0tbaEs7e6oQ1AADcfuwC5eoMZ
iozIAMh6IhY6wqh6NwoMBDInwrN6JAAOCg4cjA8H3+EAeh8KCQUb0aPTDAjWMiDahHpECAgACAZE
iPSUSACAwYID6JqwS2DvXagHCvw5GDHEAroPFkTU2kakgKACBLIdanCAXz+Eejxo6GfR4Sc9GxAU
aCeomY0jDKDR4uhRkAEHDwzpAWJgEAKE6DyM2OESlB4LBH4GRQcQQQsPG/F1LKBBA8iW+EAQaOHg
ZNNT0wgwKDvIQwEDLf+C7dRagIECsQRsGBKhgcABEPuQZvhRooTGQelGqABgA4SFoA8Kl8jwQPEL
ZA02vOBgg8MLX4XyvbCRgkMFuTU/lLDX2HDNDUNAMACgYYSgEi9mtqhQYohOVzwRKADSAu5vdLYJ
jKhA4KigDy0SJHBXs8KMBQAIAFiQoAQAHQzYUSOo4YEeHSW1Y1/AgMNUdLkHJZDxAvGIleoJENDw
A50NGbMB0JMg2gmYnQy2vRKcAg2goF8FhDSgAABxvdAcUnwZYABT6JywgAHyaOBAATIM8V0LAMyg
AHa0fdcXSC14RUABCRyQAXLs/KSABvTV9AJ2/qQYlTU/6IGCDEUZOEj/gB4hgGAVCtIlXFp23YjO
BtagoMcJFwqS4Ybo3DAjAQpY8IEIRHDQnw4ogqRACT+8QM6MLYzgAZocMEBjfRLuA4J5H4zQnx4d
zHiUOx/84ICGM3ygww4v8ONAB4LsUIJuP+ywAWq05FOAcA1kUA0ClKIjDgE3bNklAF8yRZJaChxW
UwbnoWjXVGnV1R9iNqjlAGUaGICqUCnA+t5QRRSwAIRpeaOMW3BxaounwtFqIQHiAPDBDGTSyqVz
rAa7ITczIXDDIbWC5F1NYtmlzJV6MgCEhAwYMFwh26obmoN+oQOVN7iS8NZVwlCrAK0etMBAo3pA
SEB9qoLbqh4/zKiB/6z4sDkTaOgcoF9DhHwgY5EvEKRnCufCO1M3+DBX5VPaAVWTwHBhtYvBNxqZ
3RB6TFgENBFjKO4OeowAq5WhsWncIH2GZMgDixJgYgaAjUkACubdINMRNtsXs3n/yowOzQTf3FG1
YSJAQAoWWKNXh6tObLRU6Crdwm96pAfyIHyBtCuhNnxKo5YdyHR3aC4fDDPAMw/c9S04CyKqVSMS
0FLQXg4N88Z1F3d4TQ6Ci9hWBnCMDhAH6FmAB259mjJiHOiXQkJfN15zwWcfXN2MANANt8RDazsD
SG8j1kCtS9c0wgIzUceur0i31cKnG9CLwOyEeDD8ArYtLja5K+P+qf/uSQ0Pkki/C60hU1uyczUR
GWSgAwhren4cXxLd8EADH9SnrG0iQMFjwjSTAuigaMxDgAo8ED8gRAQBF/NX7Z5zhE+d4AEPwFgs
IleT2BWgCCxLX+bWJwiIuM8jCmhBiU6UvJpYYB4g+saLEmADRYjgCAQoywGmR0NFZCAF7jsCABRQ
F3+kzHvvkdCMijKDBNViKAuQwa8Q04H5YK8mJ5CBDCbEqiJIhzo2KRB3uLMmBCSAACF0oQbWk4AF
fAgEVnrADAgyiIOg5gF5yg529OOA11FMBrQ51g0MsB4EQU4EFXjBEN7VgBG8ACCI0cwLdpWB5ZwG
HxtoSAocc6MHVOBfkxpEhwiGgAJBpOAEkHzNCWZ3ABVY4F2nWyUADsCBErwHHTqozwjeNRRx0DKN
ZwmmMIdJzGIa85jITKYyl8nMZiIiB4PIQiRMAAAyOFOZMcimNreZzUEY4RE1uGYyAwEAIfkEBQMA
AAAsFQAPAIgAHQAAB/+AAIKDhIWGh4iJiouMjY6PgnofHRYbDZCYl4IZi3qDGZp6RDecmKanjRkn
RwgEDESojHovGgAKDhaJek2Ct7l6JQgJB6WxxrENHAkFAAsJsMeIeiAJBgwLB4kNBwsADAlDAHrc
BQTQ0eiOehYEBQwoPxUeAA1AHemRIASCBQUkh3qAMANQroS4Cs4UPMDHUJEeFQQQHAhlQQGBFAyn
7SNI4AVAffwIGBR3Y4iIhigBpiBA4MSgaTIIoMior4CDIgwcFBskQgMDDRoKphyqywZLj5FOsJyJ
TyODEwoYELhRSM8IAAigGhApTseQIVQJ6dnxAkUKFC9gifraQdQJFff/xIkoAQKFDRUmDTVoogKA
DRA/dgZ8wQEAhxMbBj34UUKBNYyCSqRgwEABgBKBo2kkMKLC0kINLM8g4pirVRm2NAH4YANBIQ0P
9JyQIcPGDwMLZLjUM6SWoDssNYwU5OEAgW4Aqs0T9AGFgUIXPwDwgHvQc+v8mhU5eWzziA9FDBxZ
Lm6DVA4ZHGw1aDXiROYKFpRjpmHBjNgv2gGoT0C3ngoAGIAAAwDMEOBW4QCQATnMKODOciLEV04L
GhTRzgIKfVDOIAW4FhGHABDQAnfGbFaBHkYRAGAkhRHQQQPqmTaCe5fogYJ8DKgAywdN2CDCLPsY
YAAIFlRgAREEIqBA/wcffGCBAwwU0IIOenTQzhEvNkDECdLpwYF8Bbyggwg6gEBQAipcskFUBHAA
hCBAoOBKNgAAoVosJq6zjwKafGAgn+mtJ86MEjUwVpQdgWZofuWsKI6cBjiw0CAkHFHAAifwRkCk
h5DQj4pi1dRClykiJU5+MtHEEoAZKIAAAon9F6JHD8TIHqETybZAZTu9lJ8BsPEUFGdVQaSkHje0
U8AJJB60QKSTDuJBC+X8IM5KiSb1WVP6gAokAX2FhkAL89QqaHsSiWMcAWYClF+6gxDRjwFvijVj
pBk8YFE5Gpyw3EMRQUZIq7Nee9RLSqXK7arEtfDTAx20YoMg5sronv84lmVryLcTR2JeAUX8I1YJ
m2rwIwnxMYDbEeHYyFJhoLnaksEay7ZtOiZGMpNIfRGQCwAV33qxHmy65C5LHQuygwH9nBPJvZJS
PIJFAU7lMgFJDxJaiADqga2pNiuMc7crIqvfDEqWEvSgQxsF78aoZj1ttVXp8/YmQxwRYgo2G8Bn
IX6Ww4vXB2srNjo5bxIVR6aujW6uI8hnwM8vLYo0IeIWSsgHQS3wgh53AmlLle0gYO1LnhUwQ5df
IxywqqBG4lkRIOugmK1say6CAwhI+V0DD9zAwY9xjyxfmzpkkAERByBgwOp6/KACCZdkANFFCu47
QwkiNCDCELQnYDT/4TUjpPoGGXzQ6ymJM6c39refi2uNNwjILwAOEHAEfpdjjsIyIrJFhxiAgMEN
QQYFsIxlyvELIFioQw7AX+8SoJBItM5j/GjBLZqFiocAQAamEkdhZEA5oGkgATJo2Qho8zeSOKAb
+0gA/mIzGxnQaWAguMZxQrQAXETigMiRYQEcpYc1CYIACVjAAmRConHQxmiCSIYM91EADrLvHi/Y
gVhsN4KdNKAzL/iHKF7wguEI4nszOYANwlgeMpbwJVvCyAE4kBeelKAvAEjBCURGiMXATI+JEUsT
yBhIrY1Aji+4E1EWychGOvKRkIykJCdJyUpakihfuKQmLWkCRzxhC5OgNMYUQknKoQQCACH5BAUD
AAAALC4ADwBvABYAAAf/gHqCg4SFhoeIiYqLjI2HDUQWFh6JDRmXDYuWmIMPNySOoaKjhxsKBgQy
HIgfCg6uKZmIGSmvDrF6DwoJBhakv8CKOwUEqDI2iB4FCAwMBB2JNwTNBA6ZGwkFCcjB3d0NBwQF
GhUlP4IiFh+DHkcF7wQqiSjiBQwKmSIOCQRD3v+/dLxD4EvQAw4zFgBh5+7duHWGdLRweE/WhxHQ
AGoMtQFBgRkQ9XwgZmChoHbjHBDzZ+iFOJUVN8ocBQSBAQ0POs0wYADUyRb3TiBAcEBWJwcEFJxo
hk9PAwtDhoREVwKEjRQqfuTM8KPEkAcZhqg4kWEQkBccbKB4seOQjhco/1JweKGjkIgfIFDYUCHV
7JATBgocKVeiRIWJBU54JeIBqAMSGgKbHGSBAIEXJaY1zaAhgYyCgoZosExgwQIZFUS24GchRYJs
6z7YYGD6TmkENqaOKLDgtWcQhEqMNm15wQyWIGR4hEe63rJULxoz0JABhGXghFKI0zFEc6YMDpyB
rrCAJ4EZKmW8EBm5hYLiBR58cLCAWAsNxHgrECGosgEGr2ggA3Z6jDBNMxpowAwqI+iRHAMOIWDZ
UBQhoF4702UABAMGOJCTICQQc0CB3ukBnniCABEYAg788MEDJIDQ4AeREaPAEE2c8AAK9RVAlwgx
MlBEAtiFgwAH/IlQQv+DehAxkAIdfPCBBQpAWIAOH+wwQmAzWLDDlxY0NAQQG3yAIU56HCDhOYKc
sAABJZAY04kEFGRDMQ5QQkhZNBbQYUgqEsPkICqIMwN/VS4QpyEc4MnfIDrMwBt2G970YS479cTQ
dDl1R0AKBjmAgAb8GTinA6j48oE7/bCCHwGpDeJSh2UREiIxvoTTYUZHoRIrIdbF1NFNIX2Q6WRn
5iSCBhDWlRkB2Jm6WXh16tGBRy3oaQiNqPCqBz0EoGDIA6gS0OAQ2fx3gAWyCGTPBoZkNg5/w2pQ
7LGboumgZevpapK031HrSxPF6LttZAa0NYh28RjSQJWXObWUOJYdsA7/EA4RYUhlD+lR7708IQuU
vioiAKWIsgBsosB6EPzRVIRwmzAhdxKwSiF0DgoECkWIk0BRTvo52SA/FEwvh/YOYqzQ+V4aTgsq
tSqIynT6ssOK3hKyLE8KCxJsU4Q0RswNhZCQAoQIEPGApFITcgIBJl9jU9KCGBsyOzNwOoi8PJE6
CNUsk2sAUbUOkonMXevBMUGFzEpqA0blElm1RipQeC6oLnCCIB8rLSkC8J50hN6hGtCzPH+XWLUg
FWTzKRBgeXDCjAgnrouhWjUgwm7abJ4BClqleMTgbf1QH24kXEKEmgZky/ncIT2A35EPyJes2+Iw
kDjgqQpCSzYevXKEyHrscV3IBssMHqDPB2y1jwMHHCDpAgeU1QAHrrunQBHMwDlI5wvLngM0EB0G
JKAFjwJRKsDGOhkkwBom6sxnOsEBBLypN6dJzQeGlIDQEaID9ClNAkyDABR8CDy+GeECFKCtBoCA
N6W5oAbYJIgOOLAAU9lBEd6UCh1VoAIjuJweSvACD6boBRUYQiYaMIQK0KUQOzhBCuKXla2M4Icw
M0gJOBC/FJwgcXo4iw3ix4EfCLFJL5jiATgwhATWDYlBLJsK4ocCIAQCACH5BAUDAAAALC4ADwBw
ABYAAAf/gHqCg4SFhoeIiYqLjI2IHzcWOw2JDRmXlIuXmINAHZmOoaKjhA8qLQgLLR6JJw4KCg4d
ikOvsRuCFQQJKKCkv8CGGSkJBbsIrIgoCQwMvJUKBM0JN4LRBQbJwdvBJcUGKj8VH3oNO7OEHAQF
7Efkhx0I7MbVeicJCQcZ3Py/NgQEUhCqlYBDIXXzCIxQto4dgXoNLJR40K+iKAUMCFQgtGwBiIPr
HBRAoMCXIA8tDDjQQM+iS1IYCQwhpALgx3TSXjgwwGCHoRc5RT4URGTIEHSENpxAkYJDBRKCdhj1
ueOECiCDPgxRYcMGiB8UCz0ooSKFVwsmd7zgYIPDC6yC/8bWKsCAQ4m7JQ4wQHCgxBC0etQRaHIC
oIpCGRwQcECE5VB7MmQcIKTjAECACxKU1KMisoohBBbI2KinwozQC+4AdGCBEAkFCzLjayFikI4U
qWLHRoCiNhGA8zJenmdglwaKgpuQMGBAQ+1BFmw+cFwPaMBBHjSsI1DEwYwEDiiBWKegxQICo+0l
MICg+Wn2g+NeaxHLAO2Tio21cFxAcwYSwLEDHwHyzJOKA8gBVIIelhGw4CApEGAAEdO1pId1ApVj
GTsnkPDAByXYsM94dBVwggUvdNDBOnxt8MEHP2jAkwbkNLFAc0BYAsQJtTUQYQFFVOCBCESowEB/
J5izgf8CxYEAxA47AIEbATYAsUGOgQE0E2gETCYICcZMJgJ1gmAoyA0sLkRIA+Kx+KAglpG0zyA7
sLPARhUsQNIhG7gJUnNhxTTTIDURcNMggs005pFQ2aOlHh+QeSFAGarDgJeHjMfAZie1YEwThkR4
XQkLsPNCWIOcsMCmJhHhEDoxqSlIoYcKkqgg4xFwgh4POICAc5BKamYDCiBAwAuJ5IoCISsCqcNP
0pQ05nYOvPCOHqIaJJaMMlmTkayc2QRSt3q4ikB4TRgmSKQWmtlrcYNmqi5068xw7SC6bLrPDg6s
asACGoDKoLiI7aSRtwrRRDCij8JJoAX/9LSusJTqkVj/RqTJS8Bhg6BZwCrQshpXBfk1g1WDHJdi
8EzEfquwoePG+0NIqHDK7mNmMmisDcnOS9SrhqAAEM+lVFBEAQscVhNfhoA5Ei56xPpyrVmSy+tO
Dsl6c3UVX1hqAVAPwqYeuaZssQMZEW3bEUizXEiuk82MDVKCFKZSoC4TCpC2DFvtKDv2ZkXxdZAe
wdwMJYjQwAMWcDCiz7kUg4AKHlyyA0bnUjQCCDpQ8oANxhrUa3saWPBAAyJUwE4CGUud6joaEJHB
B5TcOojTBPAdbLtd61GCNMZoEMsC4ZENucUHFEPAEbDQ1R46L8hA3wEKYEMA1Dfsxd4r2vWXwpxR
5y2ImwVf06cARTZEBi6DMiQQNqT9ydAaZJIREuN5uyQgw2adyaB7XBxIBWpCIwt8yUA2CShVvPRw
A8WEJoGrUgGqiKW/jJWDGACRwXEY+IIXEKEQRHjBCHzxgBFU4AXJUMsLBJaVEaDgAAewwQuepYcO
dLAehqhKCmDIAbAQQisqgGEKZmiIsXBAiCeACyFKcEIlCiIDFdhhCirQgEAAACH5BAUDAAAALBYA
DwCIAB0AAAf/gACCg4SFhoeIiYqLjI2Oj4MPGwAdIpCXhBmMDYcfFh+YoaKLeiUODAQJI6OMHYQn
ih4KDoKwAEQzABo6rL2jeiMLDAgEMhW+iRYLggQzlod6LwmDHIIvMgAyq8jcjh9HBgwKQyOueh4W
mt0WCIMEQ4gPDgbUgjsFAEVA3fyLPwAFjngYpONAgRkP+LEbhOAAJ0NNClUDoIfICBL9MiKqQKAh
IQsyEDhIuK4dgBkFDBAxpCcFgSO0AEzUSHMjAQAHCE0y4OAhN3YEbHAgQMAWIRIFgg6VKehBiafq
BnmoUM3GiQ6cQJX494HqNgAZbpxAIbMCr0J6NpywkULFiGdS/0eoAIACRBOSem6UsIHAgAJCIABq
GFFiCChfC1FsYMCTpCA9sAhYUHFzIhECwg4DaHCiwDJ3OyglSKChg4NpfwHs+Hvzc4ETPjNQJiTj
nyDOLdwRVTBJj4IE9AASMokv1Q1kC1M0UEAsYiQNABxkWDoRaYEWhxtwmIaAgQYNDBJM6sBA12kA
Cf5uSGqgmQYDCAok4MAJ8jSeCmbUvr1dEL4jgsS3gW/A+XeTIOW5k8BxiLWTAgDbPDhICQAUpQcK
lQliHXYUBVPhAZWIENp45SWVwg8lVCCCA31pQKFqKcS3wD8iQMdABRk08MEL5gwxDQEo7OPBCAAS
oMADJOxAmf84oQlyTAEa3LDDBo6xkhwAH8xgQAFn6ZFTASRcmCEAG4IiDyopREWRIORVaINPwRRQ
QJOCZKAAKjnpICeXhthJjHIfMZCUcxx5NMhOPSnkIEVDEfCCIECUl5OYTJEpJ4fHybnSIeQVwMAk
j7kEgA2GUHjdBw/kwkAKZw0SqaegDuJbeXMBUGhOgxzXmKIASLiYOBnoQRkB/1Ba3aUfREOAOD4V
Qp4BM2iWwTwEHFMIEXIasIMe/QHQAgp0/gMlXI/NJuGthOg6Eq8SLldhBw9At66xGiKrBwg34cop
Yxo4Jk97LxLigZwMuPKADUQlxQAImqyyKyH3doQrurkC8PD/T4sKsgoBKsBDQGAUYVhpmREbuq8B
/UZC7VeDWKftYxYcwICgCcACz8Xl3vSgHhQLom6ViJUnIQA1QquBpo+JfOypEC5wkGbOGoCyY8vR
aogFAB0BtR4dKCC1Bhm4IidGEB9ADMg9A/Azu7LOBkBDD9FrKdNE0FMUWmzy6xhkTs8wkKwuEaCv
TvEVgWouHxdyT1IMpp1pyiX1SkikzAQsd5kU2eD0wjpkkMFKJE59FD4A8PZAAx6AEB8Bx5FgA5Wb
3dzvvQl4eoKZpqGigDpp71DejUQDLcqVgzRgtuhJj4k5lg4cmJsC8oUO+WPBhFMALTMQIB/IJHQU
UxHy2SKCwAJONxNdOC9taqvEhMRboi4M9uLc4ADAIwPIoWJD1i0LJICAZgU50DISQIDQdGA0LQAa
MAAkiAQsowAveIgOEDANd3AgKh+QEGaYoYB9POYapYPYCAQog/ix4izOiUQFXvA3mD2KQSKogAyr
1IAb1CoFIMAKlmQ4AjUN4gMj2J8NzEKIGp7gQQfIIUs6AAIkqiAdinuUbWR1A7IkEWo1yaIWt8jF
Lnrxi2AMoxjHSMYymvGMaEyjGh2hhzW6MSOBAAAh+QQFAwAAACwFAAoAmQAfAAAH/4AAgoOEhQBV
homDUEaKjo+QkZKTlJWPeoJCmpucAEIulqGio6SlpqeoqaqrrK2ur7CxsrO0tba3uJANRAAWHrmK
eg2Dw6EZN7zAqEAKBYI2yoYiCg6CBxmODdDW2A8HAAg/0aVALQQG1uOEH0cEAAwLN44b7gAEDthA
CwAL3+qhDQ4QKKChQokSgkQA+KXsgwZCKIJxqGcAH4AHCviN+BfqQwt74gRlUKEhQYdoH2YMKtDi
Q6KUgypiAyBiyEmOlogYYMmQpjkEG1A+nFFtQYVER50BkImzFImdLRSKfIggGTCHDBy8YIBAQbFB
GTJqNcC0gYUhQ3omLKECQAoVJf8UNmiCVkQDticeCNJD5AUHAChOBDXkoUJEFC9IFHrQBAQKGypG
uBREZMiLAiyPChqh0sAJQUByYdVAohrQQjdPNFlqsYGDBDIQ7v3hwN2+BTJe0FRJoAm0BAR+fUBh
YJ+gBQgO9NQzpAi/QX/3Nql9nN+RjQBOyECQqB44ADJAiNbAYMaDE+7aDtITkQGR1WUVICAQUs8I
AgwMECBaRMbnBw4Y0IIC7hCAwAcYLeDMR0UU6MBkN5wDwEMPRcccflxNiAADBRiVnQwMDIIAdwYO
wlV445X3gA4FGKCBVAt9lBFC8TFAH2XOIODADwiSAMJRAKIDgAMjWPCZCgoWcIL/DiLocEKICbSl
hw0G2iCCHiL8oBkJLXZ1wwcf3CBfi0R8sMEQmLWwGgA7WKASAyOEplYtWM1wpUAEDDGIbgRspGeN
N+oxEUE6FNJNgARNBgCX9mi2FwgDtaSHAvBgR4geSCa6zkMAqPcUSzA+QFVoDZFnJwDiJDdMBg4g
MINLf7Ym340iaKCfpYsFSIBug2xEkF6EePARfXoIVNFNYOnKKyHoMQUEVIrWCs5gV5mqEIAAFMCL
BYJEFys2Dcwqzg47FaBYItgSwO1eKriTgiHh2qhbSAYwcMAPxQgLjjyFrFbAqwA8y1K0VFELAA63
1KmQHuhlp8e7CNz0LQDhzieO/zz/KprrO8iy505EhUw632d6XDYIAQe4RARmDOxgCMZH/KLTwINI
e9ogCNuisCBcMqDABi10VczEFd+IcQtzDgIgAwx0PBEA2xAS766DEMGBOYJ4pUMRBURsCLcZBwxt
zQUTkjOd1u6VAgFFVEOAo3pmBS6lN65sz7qGYNv0es16VQhMvRWigw0cErBBBg/1acgL+Pk9c0tk
g+MyzgmnLci6Ox2hKNF0ixPWiArMlCvTyALQgTvhFJKU5sIQwqp+JTzcuOgXBQiAeGLTnJCtBJR+
Ni07i2Q7ANEJEresNoY0QgL2HLDDAw188AKQDpDuOoEFHBHXRc0BkIB4GXCwPf9fvJ1kQYEpkJBB
BiSkgMBO5woMufAGIIDCAw+49PsswQNQ8kC9IwTnkicIbTAPAQWoxgz8UzvrEQIIDeqaIFrFDwXo
JVzMA8ABHrKA0PlPBQd0jgLMcatByE9R7NlHVrJzsIQVIAEG0JgO0GGRXnlPA+BygAxiAxYVwGMQ
uNGNCFRiEkPsgED2EAQBCGClAmbEOBU8F8VO0CFBAGcBM5ANaBKQAAaohQhH2Ic7xLM/WTxgBBWo
AO30gJDSAYAXFRjBMO7ygsRcCggneNcBOPADvWRgIxVI2kV+oJ4UCOZSfdmG+IBFCBIsCwWS+Vsa
K8BIQegAdygIShmbwklgbLIRk6CsxSdDSUpYjLKUqFRFIAAAIfkEBQMAAAAsBQAPAJkAFgAAB/+A
AIKDhIWGh4iJiouMjY6PkIR6HjcARJGYmY16gxmDehsbmqOkhh8oggsanqWtAHqoggo6iXong7Ov
IAAJt66/jyIKCwW8R6zAmnrDgr2JIjMEAAgMlw8aDAwaD8ndiLYJAAUnPxWeGR1A3o96BwiCBg7I
hUODBQWXDRy8HA3r/4IaKGAAYJcgPRUcAHgBkFG7d4IIWDgkEOK9SwAy/Pgxr2GyBw4MSPx0YAGB
Ch4VtSPQIqKNQxsIAmhxMWXKDCEJdPiUAgGBETa/HSBQBMAMAy08FNKzr0iFGTVBCVJHKMONEy85
jFCqZycAEnpugFBBS5CHESoEgbDQEYCIEfv/AJzwOqhBB18cKpAY9AHACA0AGBgEUEKBAQQofgCo
FJQkAQMdUBA4WejDDAAHgNzD9wqFDABpBwFREHFQilcHZMh48YLAAhlNADQ4UXTQZAWiBm1QSMiB
P0FESBcqAMLTRGmCIBYimEB4Y9QEGACpxEDBb0EoF2zdfImptME7WhAo1vII5lcpxosTJMMC03Dr
zQsqsMNsNKMAHBDwPVW8SPMFSJPAS5UoJxMAyAFgAC/ONbYSAxs0oBACuclG2hEi6MDdKxx8JwhI
4zlFy1lp6ZHeNEcw9AIRJYRDAAfqnNUSAQp4UsECBuTywF2ePKDAYzMM4YEIQNggYAnc3AAY/wMv
ULWDYQSEhtFzD+50wgKgDdLBO/uQsKF3BQkyApYFTESIPyZKUwBdOBH0EiE/vDOSCpPFUkgJ8NAl
mzsIWJdRTnSZ6BNQBz0HHQI76VCENiJ0RgCilnxJZ5grAWDnUiceQMgO7xhAVV0DhfkCMS2MMA8s
j55WyET37AWSSIyh5hNKg+BA5VAM7KSHkQTU40FRfhLxZYdhXoMgnoekKRch9RiwzVLEnuYlAgEq
UAE3FvrEUCGKIrjTqwTE+hBlhjqWqyBmajoqucJGRewuH7QEabLpkYtdYPIYAsKjmgJgwQw4MrCA
A6LgJBKhhFiG4ETgiuuOveVWKQhO4nRAWv9SwA3rYbwLf9PTHbSKqWC+kkyqKgAfnAAYgkd8IJBI
IQ/iwYzf5uTwrOWaSxdD5Fk6SLucgbmLwcvSi/MgrBZQ1icKvOPLICKcUEwCFTzkcyE7FVAELSAx
EC5JR+cssVktRRQrEQa466F3BcywtCT1xvyBeQQMJsgGC+pkiLJpjVpAC3t9YmSf/jQM9kI5H4Rr
oJIFVuPPaQf97lQEMeCAmSIMsUuaEOuhQjgGvNDXYjkd0IAtogsijMAMzWxAdR080EDK4iygGACG
H2RkdR5koJShYwvC2ALbZqx2mK9sywBEgGnKecxuMUPAZQr+txdTMlCvEAMtlDXEYwzEg1+RAQmE
hrvNhFQA+gwO9EulAjIkEOufgf0OnIvdxWI+QmUneFo7qikeX06GJVlgxHOfaYZRxFUC6qVCHCe4
zgMu0x5C+Ag+AGhQUPRQgtZhDQC3gxpKKtCosAhCTwDwQAXehIIR9EUPTWBNffbWARCc5gAqYAsh
zhIXG1RgdAkbQSxs8ILAdQIoL7Cf6raVghIEAgAh+QQFAwAAACwGAA8AmQAbAAAH/4AAgoOEhYaH
iImKi4yNjo+QhB8dABsNkZiZGZCXgkA3m5mio4cZIC0IBAU6pK2FJ4IKDjeKJRoAChq0ACMEACmh
rsKPDTYJggsEJMOuKseCKYkNCgsADAlNAHoKqgSszOCKTdUGHIIfAA1AlOGQKr4ABUUeiBsMgwQW
2i+xD+3/hPSgIIDgAKEf1FAAdPRu0AJ+hvRwgAcgn6AGN4aIWLhQzwEEACAKUiEDgDmOi1TEE8RA
QSdJM+7dsoiypkeQIwid8KWyZiKVBE4oqMiOUIUFCIQaoLkMwK5BenYAUIjiRVMggjYAAAJL67kS
gmyoKLGxUIYfKm2AaPJSG5AX5v+qShX0oEQJBwYQ2CD0kcEBu2x9FlK5oATEk4OmAdBABC/NCrEI
eUgBsiKABA42gRDEocS9kNpGaCDg644gDT8kDx2UoAC6czYYUASgFx0JBNUEGSC0eyWAGf4EDyI8
xEMBAzNeC+qQSkUGx/oAQAZg8JyD3AUWL9DgD5agGc/4vViQ994MAAaWggWQgZo8XAVcW1+QvQWh
BQoeeFg6qDftQdltV5ZwABA2gkek5SSIQLTt8NxS0U1XXQPRWAPCMh/8YEN3uhmwWQU37ADPAR18
8EETeBlwBDo3qDKDJRkQAQA6ethAXwEvsEICCJ+B0MAOOyggW09b2UBQhUC0JZj/gQA0QZBLgnhg
n0sPQCeIhMv5QsB0hFziHQEKapMCAS0FJwgR9j3ESwItHQLEPWAG9E4BK2rzkXQ68USgIUDlVCV6
WIG2JQAiWIlnQYKAsEBLSg4CiwGZDfLBeQSsB9VA1AEQnQEnmCnIeJAGIwgJ2Vl0E56DgOALYnuO
BMACCnq32XMI1FkohFcKYtCp3h3iXYWeMBBfU0YtmlmV8DhwwmsC+bKXWXjheSqXAKhqUquEMAkA
qQxogNGqgtz6mK7pCDkoIt4pNAhzBbRATyFDkOeAP0A4YM1uM4Clx5gFGjLNPfxMS4i1rLaq7b6k
/TAQAeyIGyG5/4KGLmnqLoeA/zzfEDLCogqE8kAFqy3VQY3gQrtbTgKnWjK2/cI6SHQAHIEAlIQa
iiXCvySy01SE6FAqzMP5Ut0gGYxgHwEKqcpoIVJWREvKia6Mrbbs4ZUdqjVX9HCm0h1jwFMLeilI
xeUygChMr1LrKG0GWeALA0CDZoAGG0FdrbMsu+ryIBC1+27NuKJa3QcaCHuERgA8YAEKHPKssSAI
cKBDBhkAoQAC3W40hAo6XJLBwgq152JqhI6QXQLe2c1PATNI9UGjNVENgA5FVES2w7lyrSnmBRBw
iwO+N052Oik8M2UBCCQfXU4tDDXUUrtsgHxepw1yQHB2d+BLuwooMKBw5shAbY2Nl4EtwhEAyED6
dKsJYsEtrGGmGTSGPKACA7khM8sgYQLYfwf2KgQCGAcVBZREJOkgWwu+JxhavCBQg1jGCNpStJB8
I1CkG4QIRqAuG1glK+5DBFcG0RlPiWBz0DgBsQZRl5Ok4ARzgcoP+BFDQRStQhWAXd52yMMu9fCH
QAyiEIdIxCICEQdGTKJwAgEAIfkEBQMAAAAsBgAPAJkAHQAAB/+AAIKDhIWGh4iJiouMjY6PkIQi
gh0ZkZeYjQ2HJBYPmaChhQ0vGoIJHaKqg0OmgiOKGw6sgjcFAAqTq7uOeiAABgAEMje8ohWDBAqb
h3ooCYMvghzQqMbXiTsIAAwpgiQAep3M2I3IgwgbiB4thOc/BAAOH+X1gycLDAqWlAAICvbMESKg
ApE0d4L0bBhBL2A9FfE4uIN2wOGicwBaFNCgi1AGBwhcAcBoMSBEAL8GwUJQsSSicyAObBtiyAIB
AjEZjBTU0AI5QUReSLRxYscmHbUA6BBqYdCDJiBQvGpIqMGNXylUlOA3iATGEx2YNfgB4AADBi0B
/EDBwABAACX/PrkchIzAixKCDvzU460AELM7ATRN4IDrAw7BACwQVIQerAQHbrSAJlXwLEGLF7Qg
KSJFvEEJgDhVUWCxoJsHwD2YPOjWIJ3JECCdK6juiQemChAhROKWXgU6zzXVx+/BAWiCTBFgQG/I
YgeXAUgssZzBNg0IGBRIcLCBDWiui4QWZBz5rXbCNHhoMMM0ANeCEgtbPpt23V8FAZwgtJ9ACT3A
BTbcPuGAAA0BHAAxyQ0peACAc+8h2MQIJXhQhAH6NAXADQogUAADopEQTAFNANAAUuDoBw0DIICz
1C0EeCNaCggg4M0gIGSnwAY77MDVXPcBAMRZDsj1wCwaPABg/3CCDGiJDq6lNIgegkCIEiEgLLAR
VQB8oJxENxCwkVyEfICelLUJwsBuAJyU3yv+pEUbXYL80oBMBJSoVp3hBCgcNwTCMiYizhXQAlUZ
BLhfIfsZ4EADROjEgApcqiXmEZXiBmeb8bwJwEpy2jPFS8KkRBMA3uhxAAEGiLakgIBawkE8lR3i
nD7kfHCEMMUUYlMBmN6J3Awt3gOoIapuk5KbhIBa0qiHBAmApgV8IGJZm7z6J3F8xYNmIc79QwiU
wKhTSAfaFeCgBwB5KCZMcSLrmXSCMKtSvA7xAK0h0l450qKnattkrN3SS+gC4g5CLgGp+HppQxmc
asB2eP3CEv+yMvlrL5wX57tvIf0SEYwGGjDAUUJ+Dkxcm4D+REi4b5GnQTAkpbnyIA004QpAI2iZ
ZCFHGrAALJyyfG/HAelLKk5TrjrImwILFqtg8RBAtCEwE9KtPmROG+C3VQLzKAk6WV0IXgUUkOLG
nx7r8dJokqXmDlOmLPXKicZTQAUNqeNg1oSEKUwKbJLgzcTg3JCgIA3sJy5fghQwwiQP/LDrAhLV
2ykheL2n4Y/GKB1tqYQE/Q85UTspCBBFfDaDINn9jXDMCaXkoSDtCE10U/C9l8CpOmggJgGmgGQA
AfM8vbnCrt2iQX3XiG7IQZ7qB4AMV4dz2UElJqABVzvQjruxY4KIb+IJvQsyw6kbGoLACeQQoUDV
yRzg4CCVZZ7QogAkQAD0ofsYIUQDgIYNgh4V6JoeOkdApFRgCD95QAkyl4ITEJBNnTMECV5gA0Gg
gCGlk9sgCFgVC7wJBAYcRK96hbMfdPAAt6mH9OZEw2tQKWkCrKEOd+iIGfLwh0A0hA+DSEQg5rCI
SFTEFhqRg0Lw4IlQjCIPALCEIybxioaIwSOMUIMuevGLXuwBFseoiEAAACH5BAUDAAAALBkADwCG
ABwAAAf/gACCg4SFhoeIiYqLjI2OjwAPG4IPkJaXhR4AH5idnoh6IwAMgj+fiRaEL4okgw6rAEAt
AA6ap7eYFaMIgiW4hr6DGpWIIITGACcARQDBv8+LOgWCByUjO4I60KaDBE2IDxoGg8gdpDOt0OqI
ogYaIoNEBwUaGb/cgymIQ4XIsQDa1gksBOsAIVMIFNjDhW8GgAIBCTU4QGCGA0H+BmokKEjfoFQM
FDzjhgIFgQWwCO0gxcEGL2QiSpT4sXCQDl2DOgjiBCAVT2cZLCgDwKGCLUJ6dNoQNILYIA8jVGC0
UDOVR5G9pNLjNwTeJ24qboxSWEgqgg4mASDbsGAZTwAZ/0BMI4SASE9BDjpooCaoA1ZCBU40GPSA
A6G2qQRlOMGskAIgABpcHMcoAbavglBIZkBA7KAPDkXaIKBW0I4C7nhm8AiAMgICkC2QLmTwhgEE
Biq25lUagB6peAEckZG4wVJCRwa1IKLHQQJGvCyfIgngRVsUhEQt0JWCNLLTqQXhBJBikogONmLP
BmDjx5ARHzQwMOCA2waDADpvmsVghD0PL0wCAE4IcGAXVI2JZBcHpClwWXXz5QXABk51ws1SHrRg
wBE8NSBSEZp01xt4GnAigjgAaHaIbJkRgtNyhDygACn6ADFNAW8R5gAp2BFSAi8E6FRdR4SA9Nct
F/qWlv8oAHTAy3EifodaiQA0QVoLRxXCogF2CaLHAbwYVogoBczwwAeN2ZBlk4IU0OUgHpIy1FCs
VTlWTdMJcpxYCQ1mGAGJRWnalJwogwB+KxLgjlMPOGDAAvwUssM4BZCgR48AtMABZEy15kCFmZF2
HJ2EfBMSnpixp5gCCDBAhAgtIODAQoICQCInYh6XKAOffrYXoIYQMY0BkInQ3WwGCDZkSIOVRWQy
zwpiKlkM6TlIBW2dwGRKtd4KAHCIGiIbr06dCMAC+Axi40PpNPADmKQMqQt9qBJFWo+kDjJtvRZa
u5OGghhQRETdEjrkooiM26sgcUJbiC/ueOXlDY7y2gD/i1gW0vCc0drJ7D3+CiJmxwWH92BKWhJA
LiFShQcnmAToSohYZYrwwSwO50QKAQLmK21r9YCsak68AZuPd4OGN1HAJ3hgDxCb9qTywoIAMU5C
QDzQgAeGFYDAJECgsMFCuvBqDwdtVcfTDeIQcECzPrPZWqSgXpIknDOufPSIBgO0lyDJKVDAAurp
PQjKF81AWgJDAbFAvKrsdFEh8WoQUdwfHEEZADM82EkwdQ4oyFCDHCDDt4Js8FwRb7UyW9qu3pXA
MIXoUQHOACTQVgvjAUHAc90AJ4gHiLbVYDqj8+Vi2gDI4Dkm6SQ2iAgVvJBjlasI+YEu/klkgfAT
DqZNQQVDNJtJBT3aYBQhQYGgzwEgCFhIB8gYZIH5qf+MlAU9giDxRgAMoAAHSMACGvCACEygAhfI
wAY6cBA8eKAEBxIIACH5BAUDAAAALDAADwBvABYAAAf/gACCg4SFhoeIiYqLjI2KNyKOkoQfk5aX
mAAlDoIyI4gbnIIgih4KoqQAJBoAGiSZsLGEQwuEFYgWhEeViC+EKIIVMgAyt7LHlx8zBgAKQwAd
gh5NGYM3hZ+HGaKCHIJABQAFQMjlkj8EBUcegzoARS0P1oQIBw2HuYTegkSq5v+MKixAoIDQtVby
BB3UwMoAuUJ6UgA4MmgfwIuMRgw8QGgDAgMa7ikUlEIFAAKpCOkIl4IDAQD7EpZIOMhDNoXVNAH4
AUBEBRU3Gxwc9MrQjhOEIilqklDPNRQfuQEAwWxGtg8HbexgYMABTUFICVhItY/ESwTsBDU4UaTW
y5Mb/6AlaAVAVEEADwm9BJETQAMVCAjJKDGowYsWb2vVjaanIIMihgILvnGQo4LAPAc94OQgw76y
glqkbbAPAQNBDBJE28CMlaAEBXcUeSsoXDeRSAEwAzBDpyCThxAUiFtw98lBpwtRFsRxxEuJg3gS
QPpZUFHRgm4e6FBpB4rVxiWWqCDCwUsNhEXsSPFyAeEHGpjd0vOhwsESbm08HNIbgddXpJwWVzDi
aDBUZT31VoA7AOjBUQH9VOcPANhtdtoBfQlSDWsAIJCCSAA8I86AGnZIEABpMVAUIRlcBsCHhFiQ
XGYa1dPRRyHNAwBHAADnCwBEhMOjhNexE404/RzCIf8CJL74kg2GZFbEBw/0tuOK/DDDJESDACeQ
jYN0gCNNCAKwFQOdTSUIYTB1Y11o7NzCgAIgFsLhLoUpwAABxhBCQjgMxAUcAkWgQGITBSpFSCo8
fsmjIGKCRCZzanFEQAcZsKJBQkTCCQBSYCppAEiKbsaMiIR40EKH1zwADHJ8AfBJV1+B1aE9ADhK
SKSb6vjoEC+pwGZKnVLIDlJzJsIaqZo5YAABN7WD2oB65JLcp771WgijwWy065i+DiKCBgzMwIlD
Fbk5IXYaqcOLIctqoKiDgQEXozgtvAtpcRpkMCCEEB2AAAFeehsmuCPtuOgg9YBYLHYk7JaSnaPK
S8jpCQsUMENagkT0Eq6FbCWOB/AxY+83tuWj68EaK1rmN8ah2ubMRTZoQy0IgOBOBv2Ax2w7gAIw
4AepiAWADjZ0IBNXFp8wFwO5QePAaQrktPI3pzFwSyQvM0fAz+qCZqwgH3Cz6ms+W0yIRgZcW5ua
RxPgnyCQwf2AAopZ2TaFeV0NgIUG5XPXIGyeDACUh1v3EgEce/DoIATE1cFcLSg6yAgUFVLACyLp
4LYgKND0AXSG5JWrIIMLAqwgtViQVmaaSVNIPvkoVUGt2x5Zn6wZDvJBtEcTIlQhRxKiB0m/AdD7
Q7CH2eUHgQAAIfkEBQMAAAAsMAAPAG8AFgAAB/+AAIKDhIWGh4iJiouMjYcZO46CDZKGHpWYmZlN
hC+IkQ6CKoofh5cAM0Saq6yHPwQIDIIniB2wAAgFp4cVhCmCIwAFAJ6txqsiGgwGgzeCpQ+DHbKD
vYcNCtQANoJELYIbx+KYzgBFJIOlLQWlgtOECrWF3ILoquP4jUMAspTg/ABESNOGK5whFAC+CaKX
r6GjEgkAxBukalg0dwwQHBg0qpAHhR0ZOgJhQZDAEgD8GerQCMggDhXapdu3DcAPQiw5DKIJgBaA
I4M8vNs4TIPAToJ++KTnAcGCBTo6KRS0IIGzHQt+ShTkgNI9Qx0HgdAWMRghoAQApBVU7oAMST//
3gnaCIAngAyCNDwAsVDQxwIFogLQw1cQAkEFZJQEMmwrVwDeBgFV21eQtUJmCReaMYiBM7qDDieK
qw0lgAMqSwIYFdLvusBJs7IV5NIZ40EHTD+YOGPIJSD0Eph1kPHFRQCqOQlKsePDB5QGCNIyEGqQ
2RmqRcgF8ECZga+/GERqDeAv7AwKEIg+dPs0oZsADJSbBLrBh28IXBbyp7FQB2YL0GTaRN0Iw91A
hBTmEzoSUUKeeVHtcJgBkbA3DAHzAYBQf4WoFlgGGjADWSE6XJjhXIchVJcgCqgUyTBHAbAdZCJG
45NZD74W1QgLUIeXhQUUsQtSHhWBizOFCWMD/0uz/STTILQg0OKKDQ7yYkAIFpKWBQ2EMkM7OQIW
lScMEGjIbV8Ogp4sZhEiAlqq6RSaCtHcVIBRhrywQJmC0DSlIFfGOCMApqEAX1hhwlZMSoigKRM2
siyaDn5MAnBDCiICwBcnwzw5ywLr+emigYISxF11wiBg0GqVQUioIC0MSYijWmq40mGwERIOAwUc
8QARh4lnSAppySmqlaRmSYhP/JiZaFQlitLoMGkOUkwLDA6yoZkUiUjCjwDIOQgJRi4A37GAwirT
oACQ0BgAbbJaU3k6CsJBRKsxSIIKtlH75AdHMONApT6ZWx4heth5RCnFIACCB3htQOBF6LY7DIgC
xgXErh6/FFCttPO6GhCBRpqjGAC0ElLCWiJqwNEzDKyVEMin4TtIYwWsWjFeE4YSl82ExFmInHSd
koBgAHzwCyFVXYWYp4RyZgizH7w7iEgiqMi0A6vCy5VKNhXywwe9mKZmMEg3OchxhejRQZKWGsJ2
Ii9k6w6z/B7SNQc/zH1PCWDbG1QgACH5BAUDAAAALAcAEACYABsAAAf/gACCg4SFhoeIiYqLjI2O
j5CCFpGUlUCPIoQqgw4ALZeVoaKjpKWJI4dDgyemrY8PnYOqrqMbBoMLL4oIgymCJIIGHbTEjAVE
xbW3ggwAGYcbvL2DOgCgydiCJQSGoDMf2Yu2hATDhhyFvuHrgz8EzYTVADPsieMAIILoheAAB/kA
1D1D1C9RCQAPBFVoUGjfC2TYGBQopMtThXrQlnkrqFBbRXUf4AFrBIRbkUIDDwBYQOhWwlWK9FSg
x5LQJEITGR3EKOieIG6oCCmYB4BVQEEFRx6KJQgiPUNPD6k7pAHARUPLABhgIG3qIl47eY4b+gMA
gqGDbhACCHKQUm4A/9AOmgSR0I+KAAocIYRCmqCBRQk1kQS3UFUAGkTIG2QOwJBbe3kWGiso1jUb
ZjfgE9T2VyEFLwcxrOts0OBE7wRl6omoMKENOYO6g+dWUFTJPW+hNQpQx8lBbJHWBtKMgeZDdW/q
S3TDb4NOBuQS+q18GgDMALY1A+yUo+SxDElMPGwoOICkjgeFLgSxwGI9ZgPzawGAwCSjilp4OFRT
W2rutnknlm4M6aHOaQBEttlR59XWCET0HXJVIU+VBdhP+yAoIVzPaFdaUwHiNgh4gpxmw2n7LNgZ
AMBMmAhECkKiliDDFCDNJjfdZogCDHkI4DwCYkQiIo2Zh15ZeS3GnuQgMTKI3WsODrLDIC1k0gwC
xxGCHQr+bTdIdyLmFhdDjBhZmwe/pbhkgoVUkAAARZAGgJqGiAcAA0Q8JwiXhUS4k49fDrJfmEMC
oKSLZnoGwCb10QkimxQiAs9BH6QwIwAWTBQhIlOaxRSggiyGH26FErKpIImySEh/hsAo6Z3nkJmT
P4M4aggvjYEqiHTZhSkImYXwOQijg3wgjVKLAMESbXaRt9YiXiXkVyKqvHmhhr36igiyAJiDLQCr
PeIiKRYAK+WoiVQwC5TUaOvuu/DGK++89NZr77345qsvT0Hs6y82gQAAIfkEBQMAAAAsGAAPAIQA
HQAAB3CAAIKDhIWGh4iJiouMjY6Phh+Qk5SVlpePTZibnJ2en6ChoqODFqSnqKmqq6ytrq+wsbKz
tLW2t7i5uru8vb6/wMHCwgXDxogFLcfLg8nMzM7Px9G/BC/SgtTYwgge29/g4eLj5OXm5+jp6ok9
67eBACH5BAUDAAAALDYADwBpABYAAAf/gACCg4SFhoeIiYqLjI2FIo6RkpOUlT+DCZUfikeVnp+K
DKCjpKWIGoQjN4gVoYobprGygg2HHbO4nkOHO4OQggiIKLnEkiULwYQkkR6DKoI2gg+fl4R6rMUA
CAaFJ4Kdj4Uvg94A0QDNni2FtQAKpLXgi0WN1buGqCDQpKiG654jDhUghEAUgAOOCACohnCQhUPn
EC2YVKLUw0YOHiwjBEvQCFEzCPUjlEJQr2fmcFVLlIxQL0oJ7h1rKYiIo4HO9vGiGUvhIFQMGhbC
uUqYoCHIALQDAMTXIJsAHCBCGbFQQEEZGKUbZNBQOgRFGckz1BVpsKVNBf0S1PAigJCCnaiOMgDX
Ebgmh1quPDSOFgCzSgelBbB2oaBhhuTydUQ3myPAaJ2+yplSET1FjQkJNdTBoI5ER6YNenmIw9Gk
kdVGUiywUeZBfVtsHIQYEVQDJLImumwPteBBm5QlYs0S5aHXg8Ye2juoCTflhTr6PH120EaehZQT
r4TccfRBkAlJJcS8dKGtlAwE954ooIzAg5iXT+SWveMXFRV5CAQAIfkEBQMAAAAsMAAQAG8AFQAA
B/+AAIKCeoOGh4iDH4mMjY6PkJGGFYwbAAqCIJIAmgA6GgAzRJukpaYAJYcvjDcLgy2LjJSDNoIj
AEUAq6e8vYciggyDHYwdCIMEjRmHKIJEuQU7vtO9FoItOoMegkXAgsaDx6zJg82CJACj1OulI66H
lggaD8PiwZaItYbm7P2mQwkAHDA0yoCGZd8QEEihQlDDQzpypSgHaZuhG4j0eLvVCN0pjokwPprB
8QO4iQYAgGLUhKKnZASyOVpAbIerGYmAIFpQAATCTPYEDTH0okUiYqaagAuHytADB4jMRRRkEcBD
AMJAJcCoExGmroJw7hu0a5DYRwUAGEB6iBwjC+D/Bg4lNKjlAk0PpeYCYLFEQIFIpXE99APALLVn
AdggN5SeoLKGfryzAUSEhyE4g2pigClkPYGGCqgbxAAsAL1UBTkQduCnIdMNBqUCUIAtU0EfcjEY
fSjooBspCcyeO3CQToM/42YSdOKcoOIup/IFsCFZAdOvBSGw3WwhImtUXXscNN72c0EcbCWyZNAx
gLiFgKRENDf63qqXYue8FguAfl2ISEdMJ4KggA8A4M3Q3yAgEIDAAYWAZAh783wGoX+HgKKBN/al
1tyDjXS1kiBPqXfIB0YhYI17g6iwTCoGOMAicwvYI+EgFLoHnyCzcVCYVVEJIt02zT0ioiE/HaaN
/25sYWSAMJwA8OOGiSRz4Y2C5GhhIYkYIA0zQt4HwFwt4JedSogck16auJh5IE5AHGMAdgBMBCQA
WFKnVoUJCcRlb4ygNp1MdyJy5CGuHEGoILUQAN0hKRWQzUprDkJEWgS0hOd6ghxhyI6J5CmoRRy8
44kz7wFwqDZGXXIgMi15YANbPwgjVpEMnPCBflBdglCevG1pSHGJjeWJmAB84AA5raY1GJqHDJXS
fIaoUIgH9iiw11UKmGoIAUV8uSkiLGJiwQ0y0FUXemDWKSRMhHrwKAAJ0ATADgGlhUgJxTJnCLW0
GCLCYm0pIK5hgnTWSBMerPJjgIeIlAiLDdxwVRWqhozgmi83/IkjgSo0sTFYHmM8SCAAIfkEBQMA
AAAsBgAPAJkAHQAAB/+AAIKDhIWGh4iJiouMjY6PkIQPG5GVlpeYmZqKJYQjm6AAHYQnih6kgiSC
Gjqhro4jCwAIghWvmRYJDAAEMyKJL4QotYO2t8eGHzMGh6cZyI4WBIRDiQ7MghyCQAUARUDQ4QA/
gkengq1FLQ/ii9KDBAeIFoXagkQAqu3ItggHeoPo7WP0bpABcIZSADgyyN5AcRVkFdowzUGDh4cK
DgJhiEQ3G/YcKjIGoJSgDwCqJbpRqJWhHZ5+ETo3qImhYQAUdBLEEWOidzZ27HLAjpQsCyqypQKQ
AAHNkt0GJSBAqUMCABoAOBCkACBMXvBKXhSUIekgWeQGlZJ4SEECA1H/FSVg6ROARgWC0hZykCFk
qgIGWgxqIFLQrlEbsG0ltCGuIAO0ADg0WSgt4UIMBRWghPcRXZ8aPxFQOGhnKZz2PAYe9ImQTBuI
sQEgDUDEYg0lPnzYQXpBWg0GGFR4JmhUyqsAcAIYcaQAgc4AzAL4CsCYBuNFQU87uQyASwDyCqhC
/Xc1gKKjDT1LLIj28kGUBmXAO02Pjqj6CBFPT8jCLgA2VXcIRVqNVZcgGkUnSDAAAIENQOTlA5hg
ogyCz4DYxNeeIDYYklYRHzwwg2OEODiLhoMosItZxvwzyA3bHdhfjNP990xPaUWoGoUVEPAfIokZ
MIN+xXTUDQMwSVdE/2WryERIUjG2CJAgMMpYSII50dIBcecJouOEPDHCngNOPrbATjMtyYBxHQ7C
QE+tJTKNi1K+SKOVWLamgko9JaeUhOYJQsuUhozp5APXvFeIR4JQZ8EBP5ZSjQFEGcJRlIK4SOWd
MmIpQlZYMXOhn5KVR2FrM6CEoVZldiZdQNO0oOogoxhggAYZEFjAqIMcQEtPdW5KlpV2cdoneML8
ueM92BzLGDNkogLADE/NFtmAtBThgYiCvDpdQMSAR2gH08yQ3YFYNigbmqSmBiaHGxHCASWGEnJf
AdfyFBk93wHQwBAI3MqOs8UdEmyDuwj3zLkPpXtRwBqU+WWgiSQQG4urhcSimSBDhukdAQhA5zEi
2LQw6sFY7RLVZxgJZMhO3rbZ5qg09QtPVeWUKQhzhzDo3Y+DoMDlB+6VSIjPhKZUCMsP2TzIA7ZU
67IgOvcXSgU239AnCMYV0jWCieiV7EnElm322WinrfbabLft9ttwx20lDkwwUvcgJsit9yMhRNLD
34AH/vfeewcCACH5BAUDAAAALBQAKAAUAAMAAAYPQIBwSCwOTcakMqdsAmpBACH5BAUGAAEALCUA
HQADAA8AAAcWgAAmNYKEg4WIh4qGjImMJjxPNTV6gQAh+QQFAwAAACwUACoAAQABAAAHA4BMgQAh
+QQFjQAAACwUACoAAQABAAAGA8BcEAAh+QQFsQAAACwUABAAhgAcAAAHq4AAgoOEhYaHiImKi4yN
jo+JMpCTlJWWl5iZj0eXCZqflZygo6SlpgAFp6qrrK2ur5cEsK8ghSWEHIcoixuPu4c2s4QIpEWk
tZAvjsbCrQaWqc3Spb+qyopD09qlBjqfstvhzeDi5a7k4g7mq+jr7pkphO3S6rAN2/Pv+pj5+60e
5/y5q6epnzBkAgs9ULQg4bYKhK4lUuGwosWLGDNq3Mixo8ePIAmFCIkxEAA7

--_004_MN2PR00MB0686DE4BB6B386803B93B6B495BE0MN2PR00MB0686namp_--


From nobody Tue May 12 10:23:28 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EC13A07E7 for ; Tue, 12 May 2020 10:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1GYSmyenP-v for ; Tue, 12 May 2020 10:23:25 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD533A0780 for ; Tue, 12 May 2020 10:23:24 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id l17so2977631wrr.4 for ; Tue, 12 May 2020 10:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TK31YwjXIEquJJsuMBg/SPqgiV0tqn57MieoUPXIta0=; b=SUmJUlNfPU1/E5o2SRqqreXCI3X9U6fKOJcmkHNHVH90Tc5A5FJmWQWcpsmaKWDoRr Pvj4XDHzTQe3BPk+sVyZN9V65AbiSiwzUHCs4sVA0QKnDdUz1lirsXzhmvHW5NjSLT5N 2YQP+/JTYrETO2Yr3PnhDXjd9qyZlw5ra1F4g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TK31YwjXIEquJJsuMBg/SPqgiV0tqn57MieoUPXIta0=; b=sERDrnWbH8cHINVYNFhEvB5ldDPRWwqArbYkginTLF2vNIFQcCVrhsUrlfV1G0/iTp d3N8911lsvD4lByNpNMsr3KgmJMph0q9Trm8vLiRupNGfWjcqz8Ij6TXH1k8bHHsscr/ SZDaCTE2NnRDSuQo9UmPZRVQVJR9Lt+47cPGkRRwH7CUt771hwTW0ukIFcClFA9ok3EU O2Fqp9SMKDq7mWCQ0Qwwy2vGxP+rZc/Uj+aqdU+eHP/bsNwv9z3Gep1MZfHlkl91UhgW 47g6Zou+Uy3xHSIACTFgS90agi7Mu8Ve3TZcw5b5I/sXCcfhnMdl4iJIRhXh+0q9MmWe Z6hA==
X-Gm-Message-State: AGi0PubG1unMbizDry2taNc0kehcDHZEdGyhMjchdOKdNEVB4C+CAVnv nQT9alLDBjVXG2Qyn5th/jC9LEVU9REqFWUIct8IBjn/DO0BPA==
X-Google-Smtp-Source: APiQypLMcjucS8jja3bAC5o4x+8v76VUO2L8oC3JVquUu++Fvk2iAUQQieKmpYSCR3h7R2zp+roSNN5FVYNmBOpViW4=
X-Received: by 2002:adf:8169:: with SMTP id 96mr25907331wrm.283.1589304202591;  Tue, 12 May 2020 10:23:22 -0700 (PDT)
MIME-Version: 1.0
References:  <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>
In-Reply-To: <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>
From: Francis Pouatcha 
Date: Tue, 12 May 2020 13:23:11 -0400
Message-ID: 
To: Jim Manico 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000006f9ce105a576b890"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 17:23:27 -0000

--0000000000006f9ce105a576b890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 12, 2020 at 9:50 AM Jim Manico  wrote:

> Forgive me if this question is late or poor context, but wouldn=E2=80=99t=
 OIDC be
> a better replacement for ROPC since it=E2=80=99s essentially a authentica=
tion flow?
>
> What use case for ROPC mandates OAuth2 over OIDC?
>
We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1
forbidding the user of ROPC.


> --
> Jim Manico
> @Manicode
>
> On May 11, 2020, at 11:00 PM, Francis Pouatcha  40adorsys.de@dmarc.ietf.org> wrote:
>
> =EF=BB=BF
> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Passwor=
d
> Credentials) with the following reasoning:
>
> Auth Code Grant:
> There are  many use cases on the market where redirection based flows do
> not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the
> complexity of user agents on non controllable client devices still make
> user agent redirection a challenge.
>
> Client Credentials Grant:
> Requires the registration of an oAuth client.
> - Citing the iot device use cases Beena which do not have a comfortable
> way to have iot devices register with AS.
> - This is a registration flow for the oAuth client role  and for the RO
> (Resource Owner). Remember resource owner credentials might be sourced fr=
om
> system external to the AS  like company's LDAP. oAuth Client Credentials
> are generally managed by the AS.
> For these reasons, we shall not use Client Credential Grant to manage RO
> authorization.
>
> ROPC:
> Having an oAuth Client proxy the auth request of the RO to the AS only
> presents a security risk if the oAuth Client is a third party application=
.
> Therefore, the decision on whether to accept ROPC for a specified client
> shall be left to the AS. Discarding this use case will take a lot of
> business from oAuth servers back to the old market.
>
> Beside this, I mentioned in my previous post that there are use cases in
> the market where permanent passwords are replaced with one time passwords=
.
>
> A lot of work is also being done in the direction of having the RO send
> signed proof of ownership to the AS through the ROPC  flow using the
> password field.
>
> Therefore, I am ok with raising the attention of  implementers the same
> way we are doing with PKCE,  mentioning that ROPC  must only be used if  =
AS
> / oAuth Client can guarantee security of the RO credentials exposed to th=
e
> oAuth Client.
>
> /Francis
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--=20
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

--0000000000006f9ce105a576b890
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, May 12, 2020 at 9:50 AM Jim M=
anico <jim@manicode.com> wrot=
e:
Forgive me if this question is late or poor context, but wouldn=E2=80=
=99t OIDC be a better replacement for ROPC since it=E2=80=99s essentially a=
 authentication flow?

What use case for ROPC mandates OA=
uth2 over OIDC?
We are not talking about ROPC =
mandating=C2=A0=C2=A0OAuth2, but about=C2=A0OAuth-2.1 forbidding=C2=A0the u=
ser of ROPC.


--
Jim M=
anico
@Manicode

On May 11, 2020, at 11:00 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmar=
c.ietf.org> wrote:

=EF=BB=BF
I am against=C2=A0OAuth 2.1 discarding the use of ROPC (Resource Owner=
 Password Credentials) with the following=C2=A0reasoning:

Auth Code Grant:
There are=C2=A0 =
many use cases on the market where redirection based flows=C2=A0do not work=
. As=C2=A0 we see in the "OAuth 2.1 - require PKCE?" thread, the =
complexity of user agents on non controllable=C2=A0client devices still mak=
e user agent redirection a challenge.=C2=A0

Client Credentials Grant:
Requires the registra=
tion of an oAuth client.
- Citing the iot device use =
cases Beena which do not have a comfortable way to have iot devices registe=
r with AS.
- This is a registration flow for the oAuth client rol=
e=C2=A0 and for the RO (Resource Owner). Remember resource owner credential=
s might be sourced from system external to the AS=C2=A0 like company's =
LDAP. oAuth Client Credentials are generally=C2=A0managed by the AS.
<=
div>For these reasons, we shall not use Client Credential Grant to manage R=
O authorization.

ROPC:
Having an oAuth C=
lient proxy the auth request of the RO to the AS only presents a security r=
isk if the oAuth Client is a third party application. Therefore, the decisi=
on on whether to accept=C2=A0ROPC for a specified client shall be left to t=
he AS. Discarding this use case will take a lot of business from oAuth serv=
ers back to the old market.

Beside this, I mention=
ed in my previous post that there are use cases in the market where permane=
nt passwords are replaced with one time passwords.

A lot of work is also being done in the direction of having the RO send si=
gned proof of ownership to the AS through the ROPC=C2=A0 flow using the pas=
sword field.

Therefore, I am=
 ok with raising the attention of=C2=A0 implementers=C2=A0the same way we a=
re doing with PKCE,=C2=A0 mentioning that ROPC=C2=A0 must only be used if=
=C2=A0 AS / oAuth Client can guarantee security of the RO credentials expos=
ed to the oAuth Client.=C2=A0

/Francis
<=
/div>
-- 
<=
div>
Francis Pouatcha
=

Co-Founder and Technical Lead at adorys

_______________________________________________
OAuth=
 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi=
nfo/oauth
<=
br clear=3D"all">

-- 
Francis Pouatcha
Co-Founder and Technica=
l Lead at adorys
=



--0000000000006f9ce105a576b890--


From nobody Tue May 12 10:45:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447533A0816 for ; Tue, 12 May 2020 10:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYQiajiUvhlE for ; Tue, 12 May 2020 10:45:13 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613BA3A0841 for ; Tue, 12 May 2020 10:45:02 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id c24so5388233qtw.7 for ; Tue, 12 May 2020 10:45:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=k7aeKxRJrx2Tp+Sd17QdR4TBKfKbt+GQ5yXk2eyNvbk=; b=NljWpfhF0fk/ZF/oggfzObdZDaFNiQJKeKlgNL4sC1Lj5JpJpBR+wtVqeH4eKTnxxj gGhLaIVEHsq/yQhsoLPJMl3NhQeH3tb5pw2WVQEneCS8iLivFiZrmimcxXiiwP9XNz9F UdGbF+HQKaepNzEiY3Yk1dITEoNZvJ4UUrA1tS0u6c1f5oREfTinwxPoWGduk4SOMyg0 0+98837+h/ERcHqz/X3kyu/+ybh0tSZxDsphT6p9Vbc4QU+jZoPl/dTUzycDoBLDrVTj DHleTX4P+oJ3j0a1L9VCViwVYgLE2GAKVjNbU06VZyDNSudy1J1daBAUoy0LHJdKF1ic YAgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=k7aeKxRJrx2Tp+Sd17QdR4TBKfKbt+GQ5yXk2eyNvbk=; b=cWzxdiLsN7cpAFJLoEwrVlY6rcR+kkTv4ydY/lT5wzuuEbrUEcEVmsjdccxe5Z9PDE 94OOnZ0y3WmCWgTBveupaPtC3sORv7M0sYQH8OFpk5s0y8Yk+s7RG3isHUW5YVhuSk8z YCIA685DtL++HFuJvvTUe3n7FWE7vTlO1PZmSGnxoF8cyTSQ1xonJ6glsevvwm+cqiCP kowctcplyXpLDkorgMynogsx0U8GbA75kU0HdPgay1vBzupXU3TzLq3ixt92LEZEYiBs mrLzUi2oeMuYvruxMAMwSiRTr379TpLiq1mOc7ev6vPWcNXKMeu/UFZ7hiAT1bqjnKGr d18Q==
X-Gm-Message-State: AGi0PuaUjiboaR/k68G5ROMVPnlSnQTZNTLhxRk9WpJRBC/Qpky5P/Zu H/ZIY7VXliwgh+B+c3KtJWxsElgFIJQ=
X-Google-Smtp-Source: APiQypLbZvk6EcU0SO87rEKX+FnivmoOhSXtwO1Wyze9nT0kRzqC0EDuaU8ld+o7d8SP5ai4EPa31Q==
X-Received: by 2002:ac8:4e88:: with SMTP id 8mr23063096qtp.82.1589305500931; Tue, 12 May 2020 10:45:00 -0700 (PDT)
Received: from [10.5.134.149] (mobile-166-171-59-62.mycingular.net. [166.171.59.62]) by smtp.gmail.com with ESMTPSA id a21sm9862072qtw.24.2020.05.12.10.44.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 10:44:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-0774C34F-61CE-4670-9FAE-D7ED78BC0CCC
Content-Transfer-Encoding: 7bit
From: Jim Manico 
Mime-Version: 1.0 (1.0)
Date: Tue, 12 May 2020 13:44:58 -0400
Message-Id: <40851BF2-7C15-42FD-85A7-63FD994B1059@manicode.com>
References: 
Cc: OAuth WG 
In-Reply-To: 
To: Francis Pouatcha 
X-Mailer: iPhone Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 17:45:15 -0000

--Apple-Mail-0774C34F-61CE-4670-9FAE-D7ED78BC0CCC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 forbi=
dding the user of ROPC.

Absolutely and this seems like a good thing. ROPC seems very close to a use c=
ase that calls for OIDC instead of a OAuth2x token so I endorse the move.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 12, 2020, at 1:23 PM, Francis Pouatcha  wrote:
>=20
> =EF=BB=BF
>=20
>=20
>> On Tue, May 12, 2020 at 9:50 AM Jim Manico  wrote:
>> Forgive me if this question is late or poor context, but wouldn=E2=80=99t=
 OIDC be a better replacement for ROPC since it=E2=80=99s essentially a auth=
entication flow?
>>=20
>> What use case for ROPC mandates OAuth2 over OIDC?
> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 forbi=
dding the user of ROPC.
>=20
>>=20
>> --
>> Jim Manico
>> @Manicode
>>=20
>>>> On May 11, 2020, at 11:00 PM, Francis Pouatcha  wrote:
>>>>=20
>>> =EF=BB=BF
>>> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Passwo=
rd Credentials) with the following reasoning:
>>>=20
>>> Auth Code Grant:
>>> There are  many use cases on the market where redirection based flows do=
 not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the complex=
ity of user agents on non controllable client devices still make user agent r=
edirection a challenge.=20
>>>=20
>>> Client Credentials Grant:
>>> Requires the registration of an oAuth client.
>>> - Citing the iot device use cases Beena which do not have a comfortable w=
ay to have iot devices register with AS.
>>> - This is a registration flow for the oAuth client role  and for the RO (=
Resource Owner). Remember resource owner credentials might be sourced from s=
ystem external to the AS  like company's LDAP. oAuth Client Credentials are g=
enerally managed by the AS.
>>> For these reasons, we shall not use Client Credential Grant to manage RO=
 authorization.
>>>=20
>>> ROPC:
>>> Having an oAuth Client proxy the auth request of the RO to the AS only p=
resents a security risk if the oAuth Client is a third party application. Th=
erefore, the decision on whether to accept ROPC for a specified client shall=
 be left to the AS. Discarding this use case will take a lot of business fro=
m oAuth servers back to the old market.
>>>=20
>>> Beside this, I mentioned in my previous post that there are use cases in=
 the market where permanent passwords are replaced with one time passwords.
>>>=20
>>> A lot of work is also being done in the direction of having the RO send s=
igned proof of ownership to the AS through the ROPC  flow using the password=
 field.
>>>=20
>>> Therefore, I am ok with raising the attention of  implementers the same w=
ay we are doing with PKCE,  mentioning that ROPC  must only be used if  AS /=
 oAuth Client can guarantee security of the RO credentials exposed to the oA=
uth Client.=20
>>>=20
>>> /Francis
>>> --=20
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead at adorys
>>> https://adorsys-platform.de/solutions/
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> --=20
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/

--Apple-Mail-0774C34F-61CE-4670-9FAE-D7ED78BC0CCC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

> We are not talking about ROPC mandating  =
OAuth2, but about OAuth-2.1 forbidding the user of ROPC.
Absolutely and this seems like a good thing. ROPC seems very close to a use=
 case that calls for OIDC instead of a OAuth2x token so I endorse the move.<=
br>
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On May 12, 2020, at 1=
:23 PM, Francis Pouatcha <fpo@adorsys.de> wrote:

<=
/div>
=EF=BB=BF


On Tue, May 12, 2020 at 9:50 AM Jim Manico <jim@manicode.com> wrote:
Forgive me if this q=
uestion is late or poor context, but wouldn=E2=80=99t OIDC be a better repla=
cement for ROPC since it=E2=80=99s essentially a authentication flow?
What use case for ROPC mandates OAuth2 over OIDC?
We are not talking about ROPC mandating  OAuth2, b=
ut about OAuth-2.1 forbidding the user of ROPC.

--
Jim Manico
@Manicode

On May 11, 2020, at 11:00 P=
M, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

=EF=BB=BF
I am against OAuth 2.1 discardin=
g the use of ROPC (Resource Owner Password Credentials) with the following&n=
bsp;reasoning:

Auth Code Grant:
There are  many use cases on the market where redirectio=
n based flows do not work. As  we see in the "OAuth 2.1 - require P=
KCE?" thread, the complexity of user agents on non controllable client d=
evices still make user agent redirection a challenge. 

Client Credentials Grant:
Require=
s the registration of an oAuth client.
- Citing the io=
t device use cases Beena which do not have a comfortable way to have iot dev=
ices register with AS.
- This is a registration flow for the oAuth=
 client role  and for the RO (Resource Owner). Remember resource owner c=
redentials might be sourced from system external to the AS  like compan=
y's LDAP. oAuth Client Credentials are generally managed by the AS.
For these reasons, we shall not use Client Credential Grant to manage=
 RO authorization.

ROPC:
Having an oAuth C=
lient proxy the auth request of the RO to the AS only presents a security ri=
sk if the oAuth Client is a third party application. Therefore, the decision=
 on whether to accept ROPC for a specified client shall be left to the A=
S. Discarding this use case will take a lot of business from oAuth servers b=
ack to the old market.

Beside this, I mentioned in m=
y previous post that there are use cases in the market where permanent passw=
ords are replaced with one time passwords.

A lot of=
 work is also being done in the direction of having the RO send signed proof=
 of ownership to the AS through the ROPC  flow using the password field=
.

Therefore, I am ok with rai=
sing the attention of  implementers the same way we are doing with=
 PKCE,  mentioning that ROPC  must only be used if  AS / oAut=
h Client can guarantee security of the RO credentials exposed to the oAuth C=
lient. 

/Francis
-- 
=

Francis Pouatcha
Co-Founder and T=
echnical Lead at adorys
<=
/div>

_______________________________________________
OAuth m=
ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth


-- 
=

Francis Pouatcha
Co-Founder and Technical Lead at a=
dorys
<=
/div>


=

--Apple-Mail-0774C34F-61CE-4670-9FAE-D7ED78BC0CCC--


From nobody Tue May 12 11:19:28 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D2C3A08CD for ; Tue, 12 May 2020 11:19:26 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpFnO47E0ljS for ; Tue, 12 May 2020 11:19:23 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04CF3A08C7 for ; Tue, 12 May 2020 11:19:23 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id x5so6042919ioh.6 for ; Tue, 12 May 2020 11:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FIPqdsxdryEkXyYdnCKYLZKI9jNdY/CuebmAzVJcPC4=; b=g2GTtRtHxriQ68ANaKDv5YDkR/Z3r9EroLFhfot8LD6deFfM9NdeU9NKCnZOyq9Hlu cIBYpnZIfULmEbpX/U3pvoEUPSSF2JbneePDBZiWBg0Xs/qQCPdrDFjheMkUJNV07wjA ULvrL7ce58trBZEvZDkVy9O98pbLE6538/gZvH6W2/0IR+nycs0hExTUiCZjC2LdzI7u vXO1x5USqOLWBECGNgpUvWVFJ4pfFYNUkfa2nKMYT4QDuokLC4GF/WskT10agHqQdTZl TEuZvJC6PNX4w1XoQGpnbkPI2DuUtMRgpvL+1FOR467PYzHgSEvBfLZ1TdEC2H7zQw7j 0T2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FIPqdsxdryEkXyYdnCKYLZKI9jNdY/CuebmAzVJcPC4=; b=ft/JWimXAZwZWIKd7F8Pj19qAowXXOeU+Mi/IZqm2GB83CbUybfYq4CQGW8FU+G0cZ akTImjNbIsgFo0zLxpCVE45KfJ9yw0XRNViLrIRyBn4mE9xeP2DnKZ0OUO2g48EOYwDm l4xZKyGnejXqe8cPWu4tidKuzXJWfUR+k78Ozf0Ye+Eu6DeDQJxXlSOoEfxNR47Ah7H+ iXSJVeXHLCHDzFHUQVvTTTNG7Qu5OSYk9UXAAUPHokhIqR8b2oXIq5XIvPOjzidl8Wd5 yXcJlzWA2zLTOrzwWxFcLFXh6/msUyf5342ui+1hHbvK4vFA//HLGck+5JiNzPWs7zim fK0Q==
X-Gm-Message-State: AGi0PuYMVev5EqIVEPJM4r2fenFUTqlUaH4IiApeCmOp/NSwlN6ooDT4 bcaLn9VK2F2MuTc1bQpN37ORA1PsCxGE1A==
X-Google-Smtp-Source: APiQypJwLUzQ+D0opxDPKlWayRWLA9oauzcQBy7nii/9pRwdVsgxu6XqLQhrHK53oco6UXBI+7yIhg==
X-Received: by 2002:a6b:bc85:: with SMTP id m127mr21183812iof.89.1589307562400;  Tue, 12 May 2020 11:19:22 -0700 (PDT)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com. [209.85.166.44]) by smtp.gmail.com with ESMTPSA id t22sm6020752iom.49.2020.05.12.11.19.21 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 11:19:21 -0700 (PDT)
Received: by mail-io1-f44.google.com with SMTP id j8so15096796iog.13 for ; Tue, 12 May 2020 11:19:21 -0700 (PDT)
X-Received: by 2002:a5d:9244:: with SMTP id e4mr21240690iol.133.1589307561082;  Tue, 12 May 2020 11:19:21 -0700 (PDT)
MIME-Version: 1.0
References:  <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com> 
In-Reply-To: 
From: Aaron Parecki 
Date: Tue, 12 May 2020 11:19:10 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Francis Pouatcha 
Cc: Jim Manico , OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000009e090705a577806b"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 18:19:26 -0000

--0000000000009e090705a577806b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1
forbidding the user of ROPC.

Keep in mind that while the Security BCP explicitly forbids the use of the
Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it
in the first place. Subtle difference.

Aaron Parecki


On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha  wrote:

>
>
> On Tue, May 12, 2020 at 9:50 AM Jim Manico  wrote:
>
>> Forgive me if this question is late or poor context, but wouldn=E2=80=99=
t OIDC be
>> a better replacement for ROPC since it=E2=80=99s essentially a authentic=
ation flow?
>>
>> What use case for ROPC mandates OAuth2 over OIDC?
>>
> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1
> forbidding the user of ROPC.
>
>
>> --
>> Jim Manico
>> @Manicode
>>
>> On May 11, 2020, at 11:00 PM, Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> wrote:
>>
>> =EF=BB=BF
>> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner
>> Password Credentials) with the following reasoning:
>>
>> Auth Code Grant:
>> There are  many use cases on the market where redirection based flows do
>> not work.. As  we see in the "OAuth 2.1 - require PKCE?" thread, the
>> complexity of user agents on non controllable client devices still make
>> user agent redirection a challenge.
>>
>> Client Credentials Grant:
>> Requires the registration of an oAuth client.
>> - Citing the iot device use cases Beena which do not have a comfortable
>> way to have iot devices register with AS.
>> - This is a registration flow for the oAuth client role  and for the RO
>> (Resource Owner). Remember resource owner credentials might be sourced f=
rom
>> system external to the AS  like company's LDAP. oAuth Client Credentials
>> are generally managed by the AS.
>> For these reasons, we shall not use Client Credential Grant to manage RO
>> authorization.
>>
>> ROPC:
>> Having an oAuth Client proxy the auth request of the RO to the AS only
>> presents a security risk if the oAuth Client is a third party applicatio=
n.
>> Therefore, the decision on whether to accept ROPC for a specified client
>> shall be left to the AS. Discarding this use case will take a lot of
>> business from oAuth servers back to the old market.
>>
>> Beside this, I mentioned in my previous post that there are use cases in
>> the market where permanent passwords are replaced with one time password=
s.
>>
>> A lot of work is also being done in the direction of having the RO send
>> signed proof of ownership to the AS through the ROPC  flow using the
>> password field.
>>
>> Therefore, I am ok with raising the attention of  implementers the same
>> way we are doing with PKCE,  mentioning that ROPC  must only be used if =
 AS
>> / oAuth Client can guarantee security of the RO credentials exposed to t=
he
>> oAuth Client.
>>
>> /Francis
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000009e090705a577806b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


>=C2=A0We are not talking about ROPC m=
andating=C2=A0=C2=A0OAuth2, but about=C2=A0OAuth-2.1 forbidding=C2=A0the us=
er of ROPC.

Keep in mind that while th=
e Security BCP explicitly forbids the use of the Password grant in OAuth 2.=
0, technically=C2=A0OAuth 2.1 just never includes it in the first place. Su=
btle difference.

Aaron Parecki


On Tu=
e, May 12, 2020 at 10:23 AM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:


On Tue, May 12, 2020 at 9:50 AM Jim Manico <jim@manicode.com> wrote:<=
br>
Forgive me if =
this question is late or poor context, but wouldn=E2=80=99t OIDC be a bette=
r replacement for ROPC since it=E2=80=99s essentially a authentication flow=
?

What use case for ROPC mandates OAuth2 over OIDC?
We are not talking about ROPC mandating=C2=A0=C2=
=A0OAuth2, but about=C2=A0OAuth-2.1 forbidding=C2=A0the user of ROPC.
=



--
Jim Manico
=
@Manicode

On May =
11, 2020, at 11:00 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>=
 wrote:

=EF=BB=BF
I am against=
=C2=A0OAuth 2.1 discarding the use of ROPC (Resource Owner Password Credent=
ials) with the following=C2=A0reasoning:

Auth Code Grant:
There are=C2=A0 many use cases on=
 the market where redirection based flows=C2=A0do not work.. As=C2=A0 we se=
e in the "OAuth 2.1 - require PKCE?" thread, the complexity of us=
er agents on non controllable=C2=A0client devices still make user agent red=
irection a challenge.=C2=A0

Client Cre=
dentials Grant:
Requires the registration of an oAuth=
 client.
- Citing the iot device use cases Beena whic=
h do not have a comfortable way to have iot devices register with AS.
=

- This is a registration flow for the oAuth client role=C2=A0 and for =
the RO (Resource Owner). Remember resource owner credentials might be sourc=
ed from system external to the AS=C2=A0 like company's LDAP. oAuth Clie=
nt Credentials are generally=C2=A0managed by the AS.
For these re=
asons, we shall not use Client Credential Grant to manage RO authorization.=


ROPC:
Having an oAuth Client proxy the =
auth request of the RO to the AS only presents a security risk if the oAuth=
 Client is a third party application. Therefore, the decision on whether to=
 accept=C2=A0ROPC for a specified client shall be left to the AS. Discardin=
g this use case will take a lot of business from oAuth servers back to the =
old market.

Beside this, I mentioned in my previou=
s post that there are use cases in the market where permanent passwords are=
 replaced with one time passwords.

A lot of work i=
s also being done in the direction of having the RO send signed proof of ow=
nership to the AS through the ROPC=C2=A0 flow using the password field.

Therefore, I am ok with raising=
 the attention of=C2=A0 implementers=C2=A0the same way we are doing with PK=
CE,=C2=A0 mentioning that ROPC=C2=A0 must only be used if=C2=A0 AS / oAuth =
Client can guarantee security of the RO credentials exposed to the oAuth Cl=
ient.=C2=A0

/Francis
-- 
=

Francis Pouatcha
Co-Founder an=
d Technical Lead at adorys

_______________________________________________
OAuth=
 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi=
nfo/oauth
<=
br clear=3D"all">

-- 
F=
rancis Pouatcha
Co-Founder and Technical Lead at adorys
https=
://adorsys-platform.de/solutions/

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000009e090705a577806b--


From nobody Tue May 12 12:04:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEECB3A0898 for ; Tue, 12 May 2020 12:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msXsCpMTlhUw for ; Tue, 12 May 2020 12:04:50 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5306E3A0854 for ; Tue, 12 May 2020 12:04:50 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id w19so10184291wmc.1 for ; Tue, 12 May 2020 12:04:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=g1J1o/+DT5WPar0Ip6QqX2NuNPMEikocyJwnnpfqNVM=; b=MYncb/GqOTQ1AL71I2ssGQLLpWk6JJPF/3WAzS8wn1xisUf2tZVG4lghGfcHF0WzhD vCi0n3eV0PLcm7KEkFD+/L47tOpS20Qo8371TgcPftIomxamBZWErOBwJZWA++y4KJXr a4kCI8WhJwtGrS44wY1ovr38GhOInH4A6TJ1c1BhyTQRTslFYNxdXaJb6swksv7gY/hN hvcAUmxoT896jG3LjZMWBC7LgnnGPYrx9TeKJrpqZqw9+B4KIlNzYlP87UXP+oKQTTTr aci+PzQRs6B9CuhGA2GY78O9JLBEj8dKatFfsopXl2BqaO0vZ6fsRixfnrbDEDO4foTI 9Iqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=g1J1o/+DT5WPar0Ip6QqX2NuNPMEikocyJwnnpfqNVM=; b=t00Njh6n5pairkhPoZoRvBFNWEhBGdKHaVC0VqU75nC88Qs2YGjiYUlSNiiQKnSyuD BNQIfFs67yfa/St7fRSeoYRDtXlfj+cQzJkY8T5byxVBJR2w0vMKtkdnHABYGzhHFSWM 2m+tnmhmOtiI2EC9bQVVkHUBM1Xw/vFOSCL59EDOrz26+MMDo1oB2Qg4yhRAtnhcRdlG ymF8YkmtaAU82/q81ic1bdDuIbwpkQbiiwk1POzplMJs/FJUklY/fE1zF1F03nwAjEpo dUHSwkreJvurtq5K0P+Ao4iieM+KQ71cS5f2SmKWkaygOHOjHrChqTi0vVX6xmQY0sR2 uY+g==
X-Gm-Message-State: AGi0PuYq2BRRH4p66O1cKU+ldLNBVgcuVRFzXIdWqR13VaQU0hugN3fB ENpjpA8Zo/qvJmKazl4MYAgyTyXP/8CPDJqa+jg5PjWaZOg=
X-Google-Smtp-Source: APiQypLmjO0DSSQn4aq1wDp6j4GB4qXJ3qTDsyL6rCI3pkr2jMRMFIaaizfj3cE/i3tBaiz95y5dweJ3/zhrVNbS5OY=
X-Received: by 2002:a1c:4d07:: with SMTP id o7mr41098213wmh.59.1589310288544;  Tue, 12 May 2020 12:04:48 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Tue, 12 May 2020 15:04:37 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002fc61205a5782339"
Archived-At: 
Subject: [OAUTH-WG] May 11th Interim Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 19:04:52 -0000

--0000000000002fc61205a5782339
Content-Type: text/plain; charset="UTF-8"

All,

The minuets for the May 11th interim meeting can be found here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-08/materials/minutes-interim-2020-oauth-08-202005111200

Again, thanks to Jarred Jennings for taking these minutes.

Regards,
 Rifaat

--0000000000002fc61205a5782339
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--0000000000002fc61205a5782339--


From nobody Tue May 12 12:50:37 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB403A0A3B for ; Tue, 12 May 2020 12:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JUgh5WTdg9l for ; Tue, 12 May 2020 12:50:33 -0700 (PDT)
Received: from ce-mxgw-01.corbox-factory.de (ce-mxgw-01.corbox-factory.de [185.55.154.21]) (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 0393D3A0A27 for ; Tue, 12 May 2020 12:50:32 -0700 (PDT)
Received: from DGPREX01.novatec-gmbh.de (unknown [10.60.1.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ce-mxgw-01.corbox-factory.de (MTA) with ESMTPS id 49M7h53KJsz1fxCp; Tue, 12 May 2020 21:50:29 +0200 (CEST)
Received: from DGPREX01.novatec-gmbh.de (10.60.1.15) by DGPREX01.novatec-gmbh.de (10.60.1.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 12 May 2020 21:50:28 +0200
Received: from DGPREX01.novatec-gmbh.de ([fe80::706f:64b5:2ca3:f5d6]) by DGPREX01.novatec-gmbh.de ([fe80::706f:64b5:2ca3:f5d6%6]) with mapi id 15.01.1913.007; Tue, 12 May 2020 21:50:28 +0200
From: Falk Andreas 
To: Aaron Parecki , Francis Pouatcha , "jim@manicode.com" 
CC: OAuth WG 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - recalling ROPC
Thread-Index: AQHWKAmaDDrOai3EyUeHHFrfAMH7zKikVwKAgAA7aYCAAA+kAIAALAV6
Date: Tue, 12 May 2020 19:50:28 +0000
Message-ID: <94617b561b934791933f171f5baa51cb@novatec-gmbh.de>
References:  <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com> , 
In-Reply-To: 
Accept-Language: en-GB, de-DE, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.70.3.10]
x-tm-as-product-ver: SMEX-12.5.0.1300-8.5.1020-25414.003
x-tm-as-result: No-9.787900-8.000000-10
x-tmase-matchedrid: pS5owHKhBO2nvGCyBToTI8G0UNgaZpYqGsvgUMYAn4UcI/pZs+xxL9k2 l7i3oc4z/iX1GSpmG6zQACPgtyOvxbMywGOaB4QQMTTrAcDX5/6Oz/LLJUcaHmzd8mVlXGBxigO Iyyyus7y3lYn7uPqN3l7DLRKN2ZwttE59QbvHf05cod85S7fEgHlUqG5SL+tidqUbKvsokzOsl9 uWwhFOCQ7tM/C2mX98vbg79TmW1OiDAd1DtN1q7SSnuJJeKKeEOYqKF7UrYh4ELMPQNzyJS1l4x fTSs3QpxCeSAAiLKd5W7tkPKoW8vpCSCROJF+QU+/HV1Dwcb5MpWss5kPUFdOcJOFqc/+CEKKqy c9Qq8Xr6k6aZQjEVTna6lMSHBJkl7Ma9GYskMp/805SSvoAPN1G//EzLYUavKEB1DAQzrLgA0CO gL+9tnkSstxDHEhaAskaSx6XaRv81KU/m4Dd2rmhQCsqhuTNinTcLR8+TzEpPQiQvzFiGeFUu4d MbNIOZykxJ5WoyZKt8rC3hQTP9M3ufZC0Pz+Wk0yPriHnfv3wX2zxRNhh61f/rgj9ncWz9C/G0q vgJFCcKCu5tN/4WIuPaI7IZzuYe5i92KwhuK4NQ+S0N05fR+0yQ5fRSh265H8jJDe3vPQMwnA4a zG/gS0PgW7/EUasBCYZljv4C7xopNfI+R65HNZaX2JWUPLy8FcaUNtamWKC/cnIjiwVxREqP1HO owF+7/yxMakTKjRqtnaVtsWgsS5sO9o0mINopnXRsXMVQ0benLZXtX62Wm+ZMicrOlIVJzwkZgJ kUx0xq+bvCPQ+6n9QVX76mv7SM9a/ooEbu17CJDLgwb/1K2VkMvWAuahr8zpbY1RnWitda2mNfA ynaHzp9YAKfEVHAYDX/Rt3LRlKFC0tAij/xpbdTwcNgrWQ+r2m+Pxx43FlPIjqPuNqDzP1xR4mv sb2o9Mq+4h2A1ApYKVgm72vjJg==
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--9.787900-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.5.1020-25414.003
Content-Type: multipart/mixed; boundary="_004_94617b561b934791933f171f5baa51cbnovatecgmbhde_"
MIME-Version: 1.0
x-msw-jemd-newsletter: false
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 19:50:36 -0000

--_004_94617b561b934791933f171f5baa51cbnovatecgmbhde_
Content-Type: multipart/alternative;
 boundary="_000_94617b561b934791933f171f5baa51cbnovatecgmbhde_"

--_000_94617b561b934791933f171f5baa51cbnovatecgmbhde_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBLZWVwIGluIG1pbmQgdGhhdCB3aGlsZSB0aGUgU2VjdXJpdHkgQkNQIGV4cGxpY2l0bHkgZm9y
YmlkcyB0aGUgdXNlIG9mIHRoZSBQYXNzd29yZCBncmFudCBpbiBPQXV0aCAyLjAsIHRlY2huaWNh
bGx5IE9BdXRoIDIuMSBqdXN0IG5ldmVyIGluY2x1ZGVzIGl0IGluIHRoZSBmaXJzdCBwbGFjZS4g
U3VidGxlIGRpZmZlcmVuY2UuDQoNCg0KQXMgUkZDIDY3NDkgY2xlYXJseSB0YXJnZXRzIHRoaXJk
LXBhcnR5IGFwcGxpY2F0aW9ucywgUk9QQyBuZXZlciBoYXMgYmVlbiBhIGdvb2QgZml0LiAgSXQg
YWx3YXlzIGZlbHQgbGlrZSBhIGJhZCB3b3JrYXJvdW5kIGp1c3QgZm9yIGxlZ2FjeSBhcHBsaWNh
dGlvbnMuDQoNCg0KSSBhbSBwcmltYXJpbHkgbG9va2luZyBhdCBPQXV0aCAyLjEgZnJvbSBhIGRl
dmVsb3BlcidzIHBlcnNwZWN0aXZlLiBVbmZvcnR1bmF0ZWx5LCBkZXZlbG9wZXJzIG9mdGVuIGxv
b2sgZm9yIGEgc2hvcnRjdXQgYW5kIHRoZSBlYXNpZXN0IHdheSB0byBpbXBsZW1lbnQgYSByZXF1
aXJlZCB1c2UgY2FzZS4NCg0KWW91IGNhbiBmaW5kIG1hbnkgZW50cmllcyBvbiBTdGFja092ZXJm
bG93IGRpcmVjdGluZyBkZXZlbG9wZXJzIHRvIHVzZSBST1BDIGluc3RlYWQgb2YgYSAiY29tcGxp
Y2F0ZWQiIHJlZGlyZWN0aW9uIGZsb3cuDQoNCkZyYW1ld29ya3MgbGlrZSBTcHJpbmcgU2VjdXJp
dHkgb3IgQW5ndWxhciBjbGVhcmx5IGZvbGxvdyBhICJzZWN1cmUgYnkgZGVmYXVsdCIgYXBwcm9h
Y2gsIHRoaXMgbWF5IGFsc28gYmUgYSBnb29kIGRpcmVjdGlvbiB0byBmb2xsb3cgaW4gZnV0dXJl
IHNwZWNpZmljYXRpb25zLg0KDQoNCkFzIEppbSBhbHJlYWR5IHBvaW50ZWQgb3V0LCBJIGFsc28g
Y29uc2lkZXIgdGhlIFJPUEMgYmVpbmcgYW4gYXV0aGVudGljYXRpb24gZmxvdyAoZm9yIHRydXN0
ZWQgZmlyc3QtcGFydHkgYXBwbGljYXRpb25zKSBhbmQgdGhpcyB1c2UgY2FzZSBpcyBjb3ZlcmVk
IGJ5IE9JREMuDQoNCg0KU2FtZSBhcyBmb3IgUEtDRSBhbiBBUyBtYXkgc3RpbGwgcHJvdmlkZSBS
T1BDIGluIGFuIE9BdXRoIDIuMCBjb21wYXRpYmlsaXR5IG1vZGUgdG8gbm90IGJyZWFrIGV4aXN0
aW5nIGFwcHMuDQoNCg0KVGhhdCBpcyB3aHkgSSBzdXBwb3J0IE9BdXRoIDIuMSBvbWl0dGluZyBS
T1BDLg0KDQoNCkFuZHJlYXMgRmFsaw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBYXJv
biBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT4NClNlbnQ6IDEyIE1heSAyMDIwIDIwOjE5DQpU
bzogRnJhbmNpcyBQb3VhdGNoYQ0KQ2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSBPQXV0aCAyLjEgLSByZWNhbGxpbmcgUk9QQw0KDQo+IFdlIGFyZSBub3QgdGFsa2luZyBhYm91
dCBST1BDIG1hbmRhdGluZyAgT0F1dGgyLCBidXQgYWJvdXQgT0F1dGgtMi4xIGZvcmJpZGRpbmcg
dGhlIHVzZXIgb2YgUk9QQy4NCg0KS2VlcCBpbiBtaW5kIHRoYXQgd2hpbGUgdGhlIFNlY3VyaXR5
IEJDUCBleHBsaWNpdGx5IGZvcmJpZHMgdGhlIHVzZSBvZiB0aGUgUGFzc3dvcmQgZ3JhbnQgaW4g
T0F1dGggMi4wLCB0ZWNobmljYWxseSBPQXV0aCAyLjEganVzdCBuZXZlciBpbmNsdWRlcyBpdCBp
biB0aGUgZmlyc3QgcGxhY2UuIFN1YnRsZSBkaWZmZXJlbmNlLg0KDQpBYXJvbiBQYXJlY2tpDQoN
Cg0KT24gVHVlLCBNYXkgMTIsIDIwMjAgYXQgMTA6MjMgQU0gRnJhbmNpcyBQb3VhdGNoYSA8ZnBv
PTQwYWRvcnN5cy5kZUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhZG9yc3lzLmRlQGRtYXJjLmll
dGYub3JnPj4gd3JvdGU6DQoNCg0KT24gVHVlLCBNYXkgMTIsIDIwMjAgYXQgOTo1MCBBTSBKaW0g
TWFuaWNvIDxqaW1AbWFuaWNvZGUuY29tPG1haWx0bzpqaW1AbWFuaWNvZGUuY29tPj4gd3JvdGU6
DQpGb3JnaXZlIG1lIGlmIHRoaXMgcXVlc3Rpb24gaXMgbGF0ZSBvciBwb29yIGNvbnRleHQsIGJ1
dCB3b3VsZG7igJl0IE9JREMgYmUgYSBiZXR0ZXIgcmVwbGFjZW1lbnQgZm9yIFJPUEMgc2luY2Ug
aXTigJlzIGVzc2VudGlhbGx5IGEgYXV0aGVudGljYXRpb24gZmxvdz8NCg0KV2hhdCB1c2UgY2Fz
ZSBmb3IgUk9QQyBtYW5kYXRlcyBPQXV0aDIgb3ZlciBPSURDPw0KV2UgYXJlIG5vdCB0YWxraW5n
IGFib3V0IFJPUEMgbWFuZGF0aW5nICBPQXV0aDIsIGJ1dCBhYm91dCBPQXV0aC0yLjEgZm9yYmlk
ZGluZyB0aGUgdXNlciBvZiBST1BDLg0KDQoNCi0tDQpKaW0gTWFuaWNvDQpATWFuaWNvZGUNCg0K
T24gTWF5IDExLCAyMDIwLCBhdCAxMTowMCBQTSwgRnJhbmNpcyBQb3VhdGNoYSA8ZnBvPTQwYWRv
cnN5cy5kZUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhZG9yc3lzLmRlQGRtYXJjLmlldGYub3Jn
Pj4gd3JvdGU6DQoNCu+7vw0KSSBhbSBhZ2FpbnN0IE9BdXRoIDIuMSBkaXNjYXJkaW5nIHRoZSB1
c2Ugb2YgUk9QQyAoUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHMpIHdpdGggdGhl
IGZvbGxvd2luZyByZWFzb25pbmc6DQoNCkF1dGggQ29kZSBHcmFudDoNClRoZXJlIGFyZSAgbWFu
eSB1c2UgY2FzZXMgb24gdGhlIG1hcmtldCB3aGVyZSByZWRpcmVjdGlvbiBiYXNlZCBmbG93cyBk
byBub3Qgd29yay4uIEFzICB3ZSBzZWUgaW4gdGhlICJPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/
IiB0aHJlYWQsIHRoZSBjb21wbGV4aXR5IG9mIHVzZXIgYWdlbnRzIG9uIG5vbiBjb250cm9sbGFi
bGUgY2xpZW50IGRldmljZXMgc3RpbGwgbWFrZSB1c2VyIGFnZW50IHJlZGlyZWN0aW9uIGEgY2hh
bGxlbmdlLg0KDQpDbGllbnQgQ3JlZGVudGlhbHMgR3JhbnQ6DQpSZXF1aXJlcyB0aGUgcmVnaXN0
cmF0aW9uIG9mIGFuIG9BdXRoIGNsaWVudC4NCi0gQ2l0aW5nIHRoZSBpb3QgZGV2aWNlIHVzZSBj
YXNlcyBCZWVuYSB3aGljaCBkbyBub3QgaGF2ZSBhIGNvbWZvcnRhYmxlIHdheSB0byBoYXZlIGlv
dCBkZXZpY2VzIHJlZ2lzdGVyIHdpdGggQVMuDQotIFRoaXMgaXMgYSByZWdpc3RyYXRpb24gZmxv
dyBmb3IgdGhlIG9BdXRoIGNsaWVudCByb2xlICBhbmQgZm9yIHRoZSBSTyAoUmVzb3VyY2UgT3du
ZXIpLiBSZW1lbWJlciByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscyBtaWdodCBiZSBzb3VyY2Vk
IGZyb20gc3lzdGVtIGV4dGVybmFsIHRvIHRoZSBBUyAgbGlrZSBjb21wYW55J3MgTERBUC4gb0F1
dGggQ2xpZW50IENyZWRlbnRpYWxzIGFyZSBnZW5lcmFsbHkgbWFuYWdlZCBieSB0aGUgQVMuDQpG
b3IgdGhlc2UgcmVhc29ucywgd2Ugc2hhbGwgbm90IHVzZSBDbGllbnQgQ3JlZGVudGlhbCBHcmFu
dCB0byBtYW5hZ2UgUk8gYXV0aG9yaXphdGlvbi4NCg0KUk9QQzoNCkhhdmluZyBhbiBvQXV0aCBD
bGllbnQgcHJveHkgdGhlIGF1dGggcmVxdWVzdCBvZiB0aGUgUk8gdG8gdGhlIEFTIG9ubHkgcHJl
c2VudHMgYSBzZWN1cml0eSByaXNrIGlmIHRoZSBvQXV0aCBDbGllbnQgaXMgYSB0aGlyZCBwYXJ0
eSBhcHBsaWNhdGlvbi4gVGhlcmVmb3JlLCB0aGUgZGVjaXNpb24gb24gd2hldGhlciB0byBhY2Nl
cHQgUk9QQyBmb3IgYSBzcGVjaWZpZWQgY2xpZW50IHNoYWxsIGJlIGxlZnQgdG8gdGhlIEFTLiBE
aXNjYXJkaW5nIHRoaXMgdXNlIGNhc2Ugd2lsbCB0YWtlIGEgbG90IG9mIGJ1c2luZXNzIGZyb20g
b0F1dGggc2VydmVycyBiYWNrIHRvIHRoZSBvbGQgbWFya2V0Lg0KDQpCZXNpZGUgdGhpcywgSSBt
ZW50aW9uZWQgaW4gbXkgcHJldmlvdXMgcG9zdCB0aGF0IHRoZXJlIGFyZSB1c2UgY2FzZXMgaW4g
dGhlIG1hcmtldCB3aGVyZSBwZXJtYW5lbnQgcGFzc3dvcmRzIGFyZSByZXBsYWNlZCB3aXRoIG9u
ZSB0aW1lIHBhc3N3b3Jkcy4NCg0KQSBsb3Qgb2Ygd29yayBpcyBhbHNvIGJlaW5nIGRvbmUgaW4g
dGhlIGRpcmVjdGlvbiBvZiBoYXZpbmcgdGhlIFJPIHNlbmQgc2lnbmVkIHByb29mIG9mIG93bmVy
c2hpcCB0byB0aGUgQVMgdGhyb3VnaCB0aGUgUk9QQyAgZmxvdyB1c2luZyB0aGUgcGFzc3dvcmQg
ZmllbGQuDQoNClRoZXJlZm9yZSwgSSBhbSBvayB3aXRoIHJhaXNpbmcgdGhlIGF0dGVudGlvbiBv
ZiAgaW1wbGVtZW50ZXJzIHRoZSBzYW1lIHdheSB3ZSBhcmUgZG9pbmcgd2l0aCBQS0NFLCAgbWVu
dGlvbmluZyB0aGF0IFJPUEMgIG11c3Qgb25seSBiZSB1c2VkIGlmICBBUyAvIG9BdXRoIENsaWVu
dCBjYW4gZ3VhcmFudGVlIHNlY3VyaXR5IG9mIHRoZSBSTyBjcmVkZW50aWFscyBleHBvc2VkIHRv
IHRoZSBvQXV0aCBDbGllbnQuDQoNCi9GcmFuY2lzDQotLQ0KRnJhbmNpcyBQb3VhdGNoYQ0KQ28t
Rm91bmRlciBhbmQgVGVjaG5pY2FsIExlYWQgYXQgYWRvcnlzDQpodHRwczovL2Fkb3JzeXMtcGxh
dGZvcm0uZGUvc29sdXRpb25zLw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KDQoNCi0tDQpGcmFuY2lzIFBvdWF0Y2hhDQpDby1Gb3VuZGVyIGFuZCBUZWNobmljYWwgTGVh
ZCBhdCBhZG9yeXMNCmh0dHBzOi8vYWRvcnN5cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=

--_000_94617b561b934791933f171f5baa51cbnovatecgmbhde_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9
ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t
Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh
dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsg
Zm9udC1mYW1pbHk6IFZlcmRhbmEsIEdlbmV2YSwgc2Fucy1zZXJpZiwgRW1vamlGb250LCAmcXVv
dDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssIE5v
dG9Db2xvckVtb2ppLCAmcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssICZxdW90O0FuZHJvaWQg
RW1vamkmcXVvdDssIEVtb2ppU3ltYm9sczsiIGRpcj0ibHRyIj4NCjxwPiZndDsmbmJzcDs8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIEdlbmV2YSwgc2Fucy1zZXJpZiwgRW1vamlG
b250LCAmcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkgRW1vamkm
cXVvdDssIE5vdG9Db2xvckVtb2ppLCAmcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssICZxdW90
O0FuZHJvaWQgRW1vamkmcXVvdDssIEVtb2ppU3ltYm9sczsgZm9udC1zaXplOiAxMy4zMzMzcHg7
Ij5LZWVwIGluIG1pbmQgdGhhdCB3aGlsZSB0aGUgU2VjdXJpdHkgQkNQIGV4cGxpY2l0bHkgZm9y
Ymlkcw0KIHRoZSB1c2Ugb2YgdGhlIFBhc3N3b3JkIGdyYW50IGluIE9BdXRoIDIuMCwgdGVjaG5p
Y2FsbHkmbmJzcDtPQXV0aCAyLjEganVzdCBuZXZlciBpbmNsdWRlcyBpdCBpbiB0aGUgZmlyc3Qg
cGxhY2UuIFN1YnRsZSBkaWZmZXJlbmNlLjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6IFZlcmRhbmEsIEdlbmV2YSwgc2Fucy1zZXJpZiwgRW1vamlGb250LCAmcXVvdDtB
cHBsZSBDb2xvciBFbW9qaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssIE5vdG9D
b2xvckVtb2ppLCAmcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssICZxdW90O0FuZHJvaWQgRW1v
amkmcXVvdDssIEVtb2ppU3ltYm9sczsgZm9udC1zaXplOiAxMy4zMzMzcHg7Ij48YnI+DQo8L3Nw
YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBHZW5ldmEsIHNh
bnMtc2VyaWYsIEVtb2ppRm9udCwgJnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDssICZxdW90
O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LCBOb3RvQ29sb3JFbW9qaSwgJnF1b3Q7U2Vnb2UgVUkgU3lt
Ym9sJnF1b3Q7LCAmcXVvdDtBbmRyb2lkIEVtb2ppJnF1b3Q7LCBFbW9qaVN5bWJvbHM7IGZvbnQt
c2l6ZTogMTMuMzMzM3B4OyI+QXMgUkZDIDY3NDkmbmJzcDtjbGVhcmx5IHRhcmdldHMgdGhpcmQt
cGFydHkgYXBwbGljYXRpb25zLCBST1BDIG5ldmVyDQogaGFzIGJlZW4gYSBnb29kIGZpdC4mbmJz
cDsgSXQmbmJzcDthbHdheXMgZmVsdCBsaWtlIGEgYmFkIHdvcmthcm91bmQganVzdCBmb3IgbGVn
YWN5IGFwcGxpY2F0aW9ucy48L3NwYW4+PC9wPg0KPHA+PGJyPg0KPC9wPg0KPHA+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBHZW5ldmEsIHNhbnMtc2VyaWYsIEVtb2ppRm9udCwg
JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDssICZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7
LCBOb3RvQ29sb3JFbW9qaSwgJnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LCAmcXVvdDtBbmRy
b2lkIEVtb2ppJnF1b3Q7LCBFbW9qaVN5bWJvbHM7IGZvbnQtc2l6ZTogMTMuMzMzM3B4OyI+SSBh
bSBwcmltYXJpbHkgbG9va2luZyBhdCBPQXV0aCAyLjEgZnJvbTwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOiAxMHB0OyI+Jm5ic3A7YQ0KIGRldmVsb3BlcidzIHBlcnNwZWN0aXZlLiBVbmZv
cnR1bmF0ZWx5LCBkZXZlbG9wZXJzIG9mdGVuIGxvb2sgZm9yIGEgc2hvcnRjdXQgYW5kIHRoZSBl
YXNpZXN0IHdheSB0byBpbXBsZW1lbnQgYSByZXF1aXJlZCB1c2UgY2FzZS4mbmJzcDs8L3NwYW4+
PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPllvdSBjYW4gZmluZCBtYW55
Jm5ic3A7ZW50cmllcyBvbiBTdGFja092ZXJmbG93IGRpcmVjdGluZyBkZXZlbG9wZXJzIHRvIHVz
ZSBST1BDIGluc3RlYWQgb2YgYSAmcXVvdDtjb21wbGljYXRlZCZxdW90OyByZWRpcmVjdGlvbiBm
bG93Ljwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+RnJhbWV3
b3JrcyBsaWtlIFNwcmluZyBTZWN1cml0eSBvciBBbmd1bGFyIGNsZWFybHkgZm9sbG93IGEgJnF1
b3Q7c2VjdXJlIGJ5IGRlZmF1bHQmcXVvdDsgYXBwcm9hY2gsIHRoaXMgbWF5IGFsc28gYmUgYSBn
b29kIGRpcmVjdGlvbiB0byBmb2xsb3cgaW4gZnV0dXJlIHNwZWNpZmljYXRpb25zLiZuYnNwOzwv
c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+PGJyPg0KPC9zcGFu
PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij5BcyBKaW0gYWxyZWFkeSZu
YnNwO3BvaW50ZWQgb3V0LCBJIGFsc28mbmJzcDtjb25zaWRlciB0aGUgUk9QQyBiZWluZyBhbiBh
dXRoZW50aWNhdGlvbiBmbG93IChmb3IgdHJ1c3RlZCZuYnNwO2ZpcnN0LXBhcnR5IGFwcGxpY2F0
aW9ucykgYW5kIHRoaXMgdXNlIGNhc2UmbmJzcDtpcyBjb3ZlcmVkIGJ5IE9JREMuPC9zcGFuPjwv
cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij48YnI+DQo8L3NwYW4+PC9wPg0K
PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPlNhbWUgYXMgZm9yJm5ic3A7UEtDRSZu
YnNwO2FuIEFTIG1heSZuYnNwO3N0aWxsIHByb3ZpZGUgUk9QQyBpbiBhbiZuYnNwO09BdXRoIDIu
MCBjb21wYXRpYmlsaXR5IG1vZGUgdG8gbm90IGJyZWFrIGV4aXN0aW5nIGFwcHMuJm5ic3A7PC9z
cGFuPjwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPjwvcD4NCjxwIHN0eWxlPSJmb250LWZhbWlseTog
VmVyZGFuYSwgR2VuZXZhLCBzYW5zLXNlcmlmLCBFbW9qaUZvbnQsICZxdW90O0FwcGxlIENvbG9y
IEVtb2ppJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OywgTm90b0NvbG9yRW1vamks
ICZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OywgJnF1b3Q7QW5kcm9pZCBFbW9qaSZxdW90Oywg
RW1vamlTeW1ib2xzOyBmb250LXNpemU6IDEzLjMzMzNweDsiPg0KVGhhdCBpcyB3aHkmbmJzcDtJ
IHN1cHBvcnQgT0F1dGggMi4xIG9taXR0aW5nJm5ic3A7Uk9QQy48L3A+DQo8cCBzdHlsZT0iZm9u
dC1mYW1pbHk6IFZlcmRhbmEsIEdlbmV2YSwgc2Fucy1zZXJpZiwgRW1vamlGb250LCAmcXVvdDtB
cHBsZSBDb2xvciBFbW9qaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssIE5vdG9D
b2xvckVtb2ppLCAmcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssICZxdW90O0FuZHJvaWQgRW1v
amkmcXVvdDssIEVtb2ppU3ltYm9sczsgZm9udC1zaXplOiAxMy4zMzMzcHg7Ij4NCjxicj4NCjwv
cD4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgR2VuZXZhLCBzYW5zLXNlcmlmLCBF
bW9qaUZvbnQsICZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSBF
bW9qaSZxdW90OywgTm90b0NvbG9yRW1vamksICZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90Oywg
JnF1b3Q7QW5kcm9pZCBFbW9qaSZxdW90OywgRW1vamlTeW1ib2xzOyBmb250LXNpemU6IDEzLjMz
MzNweDsiPg0KQW5kcmVhcyBGYWxrPC9wPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9
ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7
IHdpZHRoOjk4JSIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0i
bHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5
bGU9ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNA
aWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBBYXJvbiBQYXJlY2tpICZsdDthYXJvbkBwYXJlY2tp
LmNvbSZndDs8YnI+DQo8Yj5TZW50OjwvYj4gMTIgTWF5IDIwMjAgMjA6MTk8YnI+DQo8Yj5Ubzo8
L2I+IEZyYW5jaXMgUG91YXRjaGE8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlY2FsbGluZyBST1BDPC9mb250
Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRp
diBkaXI9Imx0ciI+Jmd0OyZuYnNwO1dlIGFyZSBub3QgdGFsa2luZyBhYm91dCBST1BDIG1hbmRh
dGluZyZuYnNwOyZuYnNwO09BdXRoMiwgYnV0IGFib3V0Jm5ic3A7T0F1dGgtMi4xIGZvcmJpZGRp
bmcmbmJzcDt0aGUgdXNlciBvZiBST1BDLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9k
aXY+DQo8ZGl2PktlZXAgaW4gbWluZCB0aGF0IHdoaWxlIHRoZSBTZWN1cml0eSBCQ1AgZXhwbGlj
aXRseSBmb3JiaWRzIHRoZSB1c2Ugb2YgdGhlIFBhc3N3b3JkIGdyYW50IGluIE9BdXRoIDIuMCwg
dGVjaG5pY2FsbHkmbmJzcDtPQXV0aCAyLjEganVzdCBuZXZlciBpbmNsdWRlcyBpdCBpbiB0aGUg
Zmlyc3QgcGxhY2UuIFN1YnRsZSBkaWZmZXJlbmNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+QWFyb24gUGFyZWNraTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxicj4NCjxkaXYg
Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5P
biBUdWUsIE1heSAxMiwgMjAyMCBhdCAxMDoyMyBBTSBGcmFuY2lzIFBvdWF0Y2hhICZsdDtmcG89
PGEgaHJlZj0ibWFpbHRvOjQwYWRvcnN5cy5kZUBkbWFyYy5pZXRmLm9yZyI+NDBhZG9yc3lzLmRl
QGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBj
bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRl
ci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk
aXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNs
YXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24g
VHVlLCBNYXkgMTIsIDIwMjAgYXQgOTo1MCBBTSBKaW0gTWFuaWNvICZsdDs8YSBocmVmPSJtYWls
dG86amltQG1hbmljb2RlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmppbUBtYW5pY29kZS5jb208L2E+
Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSI+
DQo8ZGl2IGRpcj0iYXV0byI+Rm9yZ2l2ZSBtZSBpZiB0aGlzIHF1ZXN0aW9uIGlzIGxhdGUgb3Ig
cG9vciBjb250ZXh0LCBidXQgd291bGRu4oCZdCBPSURDIGJlIGEgYmV0dGVyIHJlcGxhY2VtZW50
IGZvciBST1BDIHNpbmNlIGl04oCZcyBlc3NlbnRpYWxseSBhIGF1dGhlbnRpY2F0aW9uIGZsb3c/
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGF0IHVzZSBjYXNlIGZvciBST1BDIG1hbmRhdGVz
IE9BdXRoMiBvdmVyIE9JREM/PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+V2Ug
YXJlIG5vdCB0YWxraW5nIGFib3V0IFJPUEMgbWFuZGF0aW5nJm5ic3A7Jm5ic3A7T0F1dGgyLCBi
dXQgYWJvdXQmbmJzcDtPQXV0aC0yLjEgZm9yYmlkZGluZyZuYnNwO3RoZSB1c2VyIG9mIFJPUEMu
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl
IiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdDoxcHggc29saWQg
cmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0iYXV0byI+DQo8
ZGl2Pjxicj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4tLTwvZGl2Pg0KPGRpdj5KaW0gTWFuaWNv
PC9kaXY+DQo8ZGl2PkBNYW5pY29kZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5PbiBNYXkgMTEsIDIwMjAsIGF0IDExOjAwIFBNLCBG
cmFuY2lzIFBvdWF0Y2hhICZsdDtmcG89PGEgaHJlZj0ibWFpbHRvOjQwYWRvcnN5cy5kZUBkbWFy
Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYWRvcnN5cy5kZUBkbWFyYy5pZXRmLm9yZzwv
YT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu78NCjxkaXYgZGlyPSJsdHIiPg0KPGRp
diBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj5JIGFtIGFnYWluc3QmbmJzcDtPQXV0aCAyLjEg
ZGlzY2FyZGluZyB0aGUgdXNlIG9mIFJPUEMgKFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRl
bnRpYWxzKSB3aXRoIHRoZSBmb2xsb3dpbmcmbmJzcDtyZWFzb25pbmc6PC9kaXY+DQo8ZGl2IGRp
cj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXY+QXV0aCBDb2RlIEdyYW50OjwvZGl2Pg0KPGRpdiBk
aXI9Imx0ciI+VGhlcmUgYXJlJm5ic3A7IG1hbnkgdXNlIGNhc2VzIG9uIHRoZSBtYXJrZXQgd2hl
cmUgcmVkaXJlY3Rpb24gYmFzZWQgZmxvd3MmbmJzcDtkbyBub3Qgd29yay4uIEFzJm5ic3A7IHdl
IHNlZSBpbiB0aGUgJnF1b3Q7T0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPyZxdW90OyB0aHJlYWQs
IHRoZSBjb21wbGV4aXR5IG9mIHVzZXIgYWdlbnRzIG9uIG5vbiBjb250cm9sbGFibGUmbmJzcDtj
bGllbnQgZGV2aWNlcyBzdGlsbCBtYWtlIHVzZXIgYWdlbnQgcmVkaXJlY3Rpb24gYSBjaGFsbGVu
Z2UuJm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2xpZW50
IENyZWRlbnRpYWxzIEdyYW50OjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+UmVxdWlyZXMgdGhlIHJl
Z2lzdHJhdGlvbiBvZiBhbiBvQXV0aCBjbGllbnQuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4tIENp
dGluZyB0aGUgaW90IGRldmljZSB1c2UgY2FzZXMgQmVlbmEgd2hpY2ggZG8gbm90IGhhdmUgYSBj
b21mb3J0YWJsZSB3YXkgdG8gaGF2ZSBpb3QgZGV2aWNlcyByZWdpc3RlciB3aXRoIEFTLjwvZGl2
Pg0KPGRpdj4tIFRoaXMgaXMgYSByZWdpc3RyYXRpb24gZmxvdyBmb3IgdGhlIG9BdXRoIGNsaWVu
dCByb2xlJm5ic3A7IGFuZCBmb3IgdGhlIFJPIChSZXNvdXJjZSBPd25lcikuIFJlbWVtYmVyIHJl
c291cmNlIG93bmVyIGNyZWRlbnRpYWxzIG1pZ2h0IGJlIHNvdXJjZWQgZnJvbSBzeXN0ZW0gZXh0
ZXJuYWwgdG8gdGhlIEFTJm5ic3A7IGxpa2UgY29tcGFueSdzIExEQVAuIG9BdXRoIENsaWVudCBD
cmVkZW50aWFscyBhcmUgZ2VuZXJhbGx5Jm5ic3A7bWFuYWdlZCBieSB0aGUgQVMuPC9kaXY+DQo8
ZGl2PkZvciB0aGVzZSByZWFzb25zLCB3ZSBzaGFsbCBub3QgdXNlIENsaWVudCBDcmVkZW50aWFs
IEdyYW50IHRvIG1hbmFnZSBSTyBhdXRob3JpemF0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+Uk9QQzo8L2Rpdj4NCjxkaXY+SGF2aW5nIGFuIG9BdXRoIENsaWVudCBwcm94eSB0
aGUgYXV0aCByZXF1ZXN0IG9mIHRoZSBSTyB0byB0aGUgQVMgb25seSBwcmVzZW50cyBhIHNlY3Vy
aXR5IHJpc2sgaWYgdGhlIG9BdXRoIENsaWVudCBpcyBhIHRoaXJkIHBhcnR5IGFwcGxpY2F0aW9u
LiBUaGVyZWZvcmUsIHRoZSBkZWNpc2lvbiBvbiB3aGV0aGVyIHRvIGFjY2VwdCZuYnNwO1JPUEMg
Zm9yIGEgc3BlY2lmaWVkIGNsaWVudCBzaGFsbCBiZSBsZWZ0IHRvIHRoZSBBUy4gRGlzY2FyZGlu
Zw0KIHRoaXMgdXNlIGNhc2Ugd2lsbCB0YWtlIGEgbG90IG9mIGJ1c2luZXNzIGZyb20gb0F1dGgg
c2VydmVycyBiYWNrIHRvIHRoZSBvbGQgbWFya2V0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+QmVzaWRlIHRoaXMsIEkgbWVudGlvbmVkIGluIG15IHByZXZpb3VzIHBvc3QgdGhhdCB0
aGVyZSBhcmUgdXNlIGNhc2VzIGluIHRoZSBtYXJrZXQgd2hlcmUgcGVybWFuZW50IHBhc3N3b3Jk
cyBhcmUgcmVwbGFjZWQgd2l0aCBvbmUgdGltZSBwYXNzd29yZHMuPC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5BIGxvdCBvZiB3b3JrIGlzIGFsc28gYmVpbmcgZG9uZSBpbiB0aGUgZGly
ZWN0aW9uIG9mIGhhdmluZyB0aGUgUk8gc2VuZCBzaWduZWQgcHJvb2Ygb2Ygb3duZXJzaGlwIHRv
IHRoZSBBUyB0aHJvdWdoIHRoZSBST1BDJm5ic3A7IGZsb3cgdXNpbmcgdGhlIHBhc3N3b3JkIGZp
ZWxkLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+VGhlcmVmb3JlLCBJIGFtIG9rIHdpdGggcmFpc2luZyB0aGUgYXR0ZW50aW9uIG9mJm5ic3A7
IGltcGxlbWVudGVycyZuYnNwO3RoZSBzYW1lIHdheSB3ZSBhcmUgZG9pbmcgd2l0aCBQS0NFLCZu
YnNwOyBtZW50aW9uaW5nIHRoYXQgUk9QQyZuYnNwOyBtdXN0IG9ubHkgYmUgdXNlZCBpZiZuYnNw
OyBBUyAvIG9BdXRoIENsaWVudCBjYW4gZ3VhcmFudGVlIHNlY3VyaXR5IG9mIHRoZSBSTyBjcmVk
ZW50aWFscyBleHBvc2VkIHRvIHRoZSBvQXV0aCBDbGllbnQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj4vRnJhbmNpczwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwvZGl2Pg0KLS0g
PGJyPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2IGRpcj0i
bHRyIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk
aXY+DQo8ZGl2PkZyYW5jaXMgUG91YXRjaGE8L2Rpdj4NCjxkaXY+Q28tRm91bmRlciBhbmQgVGVj
aG5pY2FsIExlYWQgYXQgYWRvcnlzPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vYWRvcnN5
cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9hZG9yc3lz
LXBsYXRmb3JtLmRlL3NvbHV0aW9ucy88L2E+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+
PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48YnI+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+DQo8ZGl2IGRp
cj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4N
CjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXY+RnJh
bmNpcyBQb3VhdGNoYTwvZGl2Pg0KPGRpdj5Dby1Gb3VuZGVyIGFuZCBUZWNobmljYWwgTGVhZCBh
dCBhZG9yeXM8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9hZG9yc3lzLXBsYXRmb3JtLmRl
L3NvbHV0aW9ucy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Fkb3JzeXMtcGxhdGZvcm0uZGUv
c29sdXRpb25zLzwvYT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P
QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_94617b561b934791933f171f5baa51cbnovatecgmbhde_--

--_004_94617b561b934791933f171f5baa51cbnovatecgmbhde_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=130;
 creation-date="Tue, 12 May 2020 18:19:55 GMT";
 modification-date="Tue, 12 May 2020 18:19:55 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg==

--_004_94617b561b934791933f171f5baa51cbnovatecgmbhde_--


From nobody Tue May 12 14:38:56 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331403A0C1B for ; Tue, 12 May 2020 14:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvPeMINH4fPR for ; Tue, 12 May 2020 14:38:54 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1CA73A0C11 for ; Tue, 12 May 2020 14:38:53 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id hi11so10176969pjb.3 for ; Tue, 12 May 2020 14:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=H4UNJmPc7YJXEaEWZA4XY3YCdl3GOQVHXDtkjcdYJWg=; b=GzKYxwEBgG55qochkVCUAKz9MXx1RVATY8v2KSMK9YQvnoeLRMX8X1oF7cG0qzYNSZ /e04j7AgfMRJtFli9d3ne9gz72qKwCf08qIW4Pwt2TS6xtPdgOEaflPFEvcwXQfeBynE GePXHdzLPkBvBXkeCfBz3lxYbdwCiZDA48MFvgzknLThTzKHqEn4/9oNg1ImeB6gS/cG YucarNuYnI4j7NleTqzSPfYEoQywIvCQdd+18G3gNN6zxXrVC07QGnN2O/n9lUTsWbIL yP4X/87SvAewJopvMv6IbSA/Ei2ewXEid1oMRophkk/qB78kzztQA/0mQcRoatuJToM0 a2Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=H4UNJmPc7YJXEaEWZA4XY3YCdl3GOQVHXDtkjcdYJWg=; b=O/kNmht8CdRpLELlsQdU6WHmHhCrSEdyj0SxxPsL092mDvR2JdjuwzLZPzL5rdxsyo INw+IYJM8IVcKucQS1CSX1S6Bfp7HelKgAKn1oZ4+2/PvKAfFaOGGKGDyuMVzauhaRwf 4REz59r6kvZDjMEjKiBiq/yOtlFnGfqZNHQmpaul/qTNgkFUvmdd7MBPv1OylJakZgyg Jd+79/xbPMYv0l9nzeAmM3IASN3fpIfatMSWwzHnOKEV/k2KkdtCMlyJ8jsLXz5uP2yc U18JnFN6tDqf/48pSVDOg+Ragx+sYmGIj06mu7IIYhbImMl9xdt5vv0VyPq+1fhsoRmS lPMg==
X-Gm-Message-State: AGi0Pubp/pEUqE7abi4sp6wwu0PDGKvC7IJTCVH1vqntitv9SVWNAzFY qxiJyi61KJmIXtUvBt469grqGDfCHS2dCA==
X-Google-Smtp-Source: APiQypJLzKwyutgWvveDphBrGBCD3wJcROkC6WwyjuVRiHKJBqe5V13jO9+bCDuatUkD5dNBK+J/Wg==
X-Received: by 2002:a17:902:b694:: with SMTP id c20mr21705340pls.313.1589319533137;  Tue, 12 May 2020 14:38:53 -0700 (PDT)
Received: from node-1w7jr9qrfoxxakjm870ptorud.ipv6.telus.net (node-1w7jr9qrfoxxakjm870ptorud.ipv6.telus.net. [2001:569:7a71:1d00:c84c:ebec:f776:a3f5]) by smtp.gmail.com with ESMTPSA id 189sm12674608pfd.55.2020.05.12.14.38.52 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2020 14:38:52 -0700 (PDT)
From: Phillip Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4E5342A0-FA70-4DBD-B88A-9FCD55C75ACE"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 12 May 2020 14:38:50 -0700
References:  <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>   <94617b561b934791933f171f5baa51cb@novatec-gmbh.de>
To: OAuth WG 
In-Reply-To: <94617b561b934791933f171f5baa51cb@novatec-gmbh.de>
Message-Id: <87EC353D-267A-4144-8500-79163E006279@independentid.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 21:38:55 -0000

--Apple-Mail=_4E5342A0-FA70-4DBD-B88A-9FCD55C75ACE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

One of the use cases brought up in the ROPC thread mentioned that =
redirect was hard to do in some cases (like IoT). This reminded me of =
RFC8628, the OAuth Device Authorization Grant. I mention it because for =
*some* of the cases who say redirection is hard may be able to use the =
Device Authz Grant.

Would it be worth including a section in OAuth 2.1 referencing RFC8628 =
or, possibly incorporating it?

Phil Hunt
@independentid
phil.hunt@independentid.com




--Apple-Mail=_4E5342A0-FA70-4DBD-B88A-9FCD55C75ACE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


One of the use cases brought up in the ROPC thread mentioned =
that redirect was hard to do in some cases (like IoT). This reminded me =
of RFC8628, =
the OAuth Device Authorization Grant. I mention it because for *some* of =
the cases who say redirection is hard may be able to use the Device =
Authz Grant.

Would it be worth including a section in OAuth 2.1 =
referencing RFC8628 or, possibly incorporating it?



Phil Hunt
@independentid







=

--Apple-Mail=_4E5342A0-FA70-4DBD-B88A-9FCD55C75ACE--


From nobody Tue May 12 14:44:35 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1623A0C6C for ; Tue, 12 May 2020 14:44:28 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYagdGwm8T3N for ; Tue, 12 May 2020 14:44:26 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8133A0C92 for ; Tue, 12 May 2020 14:44:23 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id t12so13936696ile.9 for ; Tue, 12 May 2020 14:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2H90C9c0dlV5ob2shiouq94HrDER0I6an0dwEhxn4g0=; b=YX9lf/irOX3vOcqxxE0nR7aeZLKvYd3P/MzjgKaN3o3cC99ICo1Xif7ytDdrGpJGyQ JTzQLa6a8TagRyomhDABSHG291RTTkRmz5SQGXUoeJjA83de6tufE28WwgpR+S/SCzIt Y85yGMIfFFtRNxC3IBLRmZf57yJ8QLlCBq7gt2sc7qYkCNapMScXlC7U6TvXx0GFjHAr LfThVFScGW6LjGhulnZQqjkSFZhDEzmcio56wp/aS0XARw5X2SHCBu8tX/oJiEgCOOEv GxEVYeXWgHuAzqdzijUnx0Vdkh+J299WyiI+EOqji5JX/DimRX2gKnwd0robljyKtJkG 3hCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2H90C9c0dlV5ob2shiouq94HrDER0I6an0dwEhxn4g0=; b=X02weaF7b229rWD4DjLhUy4SBq/+e7mrQwhrdXsmXzZ9HVqiy5EEA8EwBI270mvFdn 7bCk6nTe8d5mgW5pn6wGcaIVcvlEB9w+AGySggmEbFtpsuTlMsWnsmm48IGL6YuHtVXM +Y5K22Uvxe4Zqkvz8JFauvqXBePu7KO7fKKEQVyD+ix6BmdW4gpJ/WfaRWSwTjar0Zw3 D39EptiQWB4NppO9yV2bLe5addmfQceXsZtYmMBNqNT7pTQA9qC29q5lOFmOfYpDm9cv E18L8RmCyq3lCW/3UV4vkkknKJ5WCMwy1KAIkVLTzxtk0v5YQGnHuRMLkZt+RsnMpLYp fp2A==
X-Gm-Message-State: AGi0PuZrIGkfRiHt8Wh8HeQQrycCymsSqhrZxMohMlCcWYiN4oD+f7Gx A20KIKMNzIccsdhVSLA983YHkjsBgas=
X-Google-Smtp-Source: APiQypICtI9fWKhHNG3RyxEGeZDmZIsj6uULeZWK/MlNh23FnnD5bEYnwjJdZRvDe7PqD5HVzs7VoA==
X-Received: by 2002:a92:a199:: with SMTP id b25mr11948568ill.77.1589319861765;  Tue, 12 May 2020 14:44:21 -0700 (PDT)
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. [209.85.166.50]) by smtp.gmail.com with ESMTPSA id q78sm5447311ilb.25.2020.05.12.14.44.20 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 14:44:20 -0700 (PDT)
Received: by mail-io1-f50.google.com with SMTP id f3so15807884ioj.1 for ; Tue, 12 May 2020 14:44:20 -0700 (PDT)
X-Received: by 2002:a5d:8a0b:: with SMTP id w11mr4766487iod.14.1589319860486;  Tue, 12 May 2020 14:44:20 -0700 (PDT)
MIME-Version: 1.0
References:  <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>   <94617b561b934791933f171f5baa51cb@novatec-gmbh.de> <87EC353D-267A-4144-8500-79163E006279@independentid.com>
In-Reply-To: <87EC353D-267A-4144-8500-79163E006279@independentid.com>
From: Aaron Parecki 
Date: Tue, 12 May 2020 14:44:09 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Phillip Hunt 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000b8075b05a57a5da8"
Archived-At: 
Subject: Re: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 21:44:34 -0000

--000000000000b8075b05a57a5da8
Content-Type: text/plain; charset="UTF-8"

I have a draft I'm about to publish after our recent discussions. One of
the changes is adding an appendix that lists out a bunch of existing OAuth
extensions, and the device grant is in there. I also replaced the
"Extension Grants" example in section 4.3 (
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.3) with
the device grant since that is deployed far wider than the SAML Assertion
grant that was in that example in RFC6749. This will be published as
version -03 in the next few days. Do you think that would be enough?

Aaron Parecki


On Tue, May 12, 2020 at 2:39 PM Phillip Hunt 
wrote:

> One of the use cases brought up in the ROPC thread mentioned that redirect
> was hard to do in some cases (like IoT). This reminded me of RFC8628, the
> OAuth Device Authorization Grant. I mention it because for *some* of the
> cases who say redirection is hard may be able to use the Device Authz Grant.
>
> Would it be worth including a section in OAuth 2.1 referencing RFC8628 or,
> possibly incorporating it?
>
> Phil Hunt
> @independentid
> phil.hunt@independentid.com
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000b8075b05a57a5da8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have a draft I'm about to publish after our recent d=
iscussions. One of the changes is adding an appendix that lists out a bunch=
 of existing OAuth extensions, and the device grant is in there. I also rep=
laced the "Extension Grants" example in section 4.3 (https:/=
/tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.3)=C2=A0with=
 the device grant since that is deployed far wider than the SAML Assertion =
grant that was in that example in RFC6749. This will be published=C2=A0as v=
ersion -03 in the next few days. Do you think that would be enough?
Aaron Parecki


On Tue, May 12, 2020 at 2:39 =
PM Phillip Hunt <phil.hun=
t@independentid.com> wrote:
One of th=
e use cases brought up in the ROPC thread mentioned that redirect was hard =
to do in some cases (like IoT). This reminded me of RFC8628, the OAuth Device Authorization Grant. I mention it be=
cause for *some* of the cases who say redirection is hard may be able to us=
e the Device Authz Grant.

Would it be w=
orth including a section in OAuth 2.1 referencing RFC8628 or, possibly inco=
rporating it?



Phil Hunt
@independentid
<=
a href=3D"mailto:phil.hunt@independentid.com" target=3D"_blank">phil.hunt@i=
ndependentid.com

<=
br>




_______________________________________________<=
br>
OAuth mailing list

OAuth@ietf.org

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




--000000000000b8075b05a57a5da8--


From nobody Tue May 12 14:54:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211563A0C29 for ; Tue, 12 May 2020 14:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level: 
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbCoVKuPZwCb for ; Tue, 12 May 2020 14:54:09 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640097.outbound.protection.outlook.com [40.107.64.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 45F7C3A0C28 for ; Tue, 12 May 2020 14:54:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gKT2rWQDD+BVtzHQczbebnRBQda0AVuwv6s6gw/0s4U1BKCgMeTn63kFJSUxvWBzDlkeWMv3s8oRZhcDKFDbJVbuE8zhPsFHGp3n2zR67xS4MkLU+KJn9JrWIRt8o5/KyeoyWga8vyo+WTLVP0H1oGmEgq1NBtZQ7sMPYSnZ14NCiF27t2er9aawhinuV6dTu2LQuVp3skIIz2axf9hjFQblyUY0R/1c2rYK3Ubp3SSv55PQlf31Q41fG7bBYKc3HxVrq5+RigH9fEBaC9N6n4JrXgg2lG//YTMm/TO2euSR/vRYphyHxSOEyfyFfZUymFFahRVWCJF9oYJJ1XiQ0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=moruf3283WC6/uwkbv8QMy9LDDRxdJZT0cL/VPPAYbU=; b=V/vxxyHu+gcUNmfbH/A2u5TXsVDQV3TJGOHtoqwPrgO4k+AJkHxldEQru7AdOLOdrHslA1KQgHwErBpkxYgvGtyJQqtF1dZnTDetUrwGLp/iWvmtfmAEFnjKQPlkIaYByzLEU1aeQmCS1sG6l7modop2xjLSJ1cct8/u25yNmBYgzU8lCm5aDOjWXfnRSQi6Dzoj+HXpwNs6VLrVJa0oZc2qujGj4kvbBEwdu9qTUpvpvtdPELqbiscfGaLzIpOk9HbXjrb+lcIpPBoz2a35AfBD8lmVTbD3QCdMxziD2QXYHIBSyG5IdH2CQOl49QTLaN6OLLn2ckXIhiK0w/xbGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=moruf3283WC6/uwkbv8QMy9LDDRxdJZT0cL/VPPAYbU=; b=VNE+jvJQdU/7ALf3/u3k1behUcpaC4YMAHkwh/z1RCspyPwM/5SupiIuLObz87nJxf+sCYcmcXkh04e+j0+ysd2Ryp/1E+9q6itBbTI0Bggap+5rKLRo+XseYAZ/1CcRqf9gfPtI4gY+OjuVsS49DvrKK904y9n3tRFMRvxb7iQ=
Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0477.namprd00.prod.outlook.com (2603:10b6:208:c6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3035.0; Tue, 12 May 2020 21:54:07 +0000
Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283%7]) with mapi id 15.20.3035.000; Tue, 12 May 2020 21:54:07 +0000
From: Mike Jones 
To: Aaron Parecki , Phillip Hunt 
CC: OAuth WG 
Thread-Topic: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?
Thread-Index: AdYop9rjj577kAzWQnSdTJuvG5aAhQ==
Date: Tue, 12 May 2020 21:54:07 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2d450927-f986-4691-b2b5-0000b4961d18; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-12T21:53:46Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e94f15fb-be54-41ce-f4a7-08d7f6befeac
x-ms-traffictypediagnostic: MN2PR00MB0477:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 0401647B7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tI0t8fOy4Dcjz7GVZ98VNXd1WE7eIp4LF9iRKvaiSvmhl+ITfw1c3TBwlbjcTahPUpPHmgyRMALDrjuZEQFC33RFhNtPDKUd3MSMJrG0sA8cgH6O1PPE2enAmipeWPOamFUXOLYhCTxMI7+FsL8x5ZNKakWgwpjBBf07lGPsCwv8z2g8bqzH9EUU6zoUeCHy6gvrB8NSXNJt41j67ZQ81l86vcxFDuHVFwYI3zdmdW6a29DIlUpy/+g6QlTZIrD83x7KN1nNhOdOY+tphwqFfZclmPO/SoGEFMoTL47ytOZc9/kc7gcItZDu8PPCFaJvqKCaNQXHKAW7ZuTApnKel9SQ9cWa3/bRrx000EVx7xgpO5hZOd+OtpG4chAKv1py6ZmMYjQoyGY4cML9vzQYmrDkMubVRPORK/BpUAlto2wipUAicIVhLDr9xZMrkKD1B09mfbOVS3gov81Xj2fX5QXmo2dkJlO6DCl/99Jbdgg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(136003)(346002)(376002)(366004)(39860400002)(33430700001)(82960400001)(33440700001)(166002)(4326008)(9686003)(55016002)(8676002)(8936002)(2906002)(186003)(82950400001)(66946007)(5660300002)(71200400001)(66476007)(66556008)(64756008)(66446008)(76116006)(52536014)(10290500003)(478600001)(8990500004)(966005)(110136005)(86362001)(316002)(7696005)(53546011)(6506007)(26005)(33656002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: +haxOBiT+O1Z2BEHVl5PDW96Sm4abEVyrrztKYPz5jMnO9rQANQRWY7EwfyzFaehb27Lrt5cDeoHDkglkYQcJIwP3gp+W+HvTLUXdRF1RqiZLQzCxjdZmvWA1XB30JDSDpzWPTQvZeMTumJmeK5Ml0W7WZ5tKM+F21I13F2wwk5YxxihkI1REYbdTK8m730rubc9Zs51siY7bQa0Aw8+zr175c40OigGfJkBGkE1E1OiWe8eVuKmTVoLaPQ3a8j4zazcj0X3vfvDD58ejzhHMS/A16VtNdQz36AFvKT+sbga9GjyDrWXWDPsD837jQJya5HPpPIRd7NI8N/z3syHJ26Oisf3TMsONjIquHMCqIRHzpgPJ+eonYKceONUjZncVONgEIQ8RbQJ991X6+mEKumpWGpyNT9SplVQar7Cc7lWBt2eCB+08P8snVqAYaQXWnPCKlya+NGZ4tEe7i7eeblvAEPpoor45vQob9yiAuM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06863577B5987174117A1B07F5BE0MN2PR00MB0686namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e94f15fb-be54-41ce-f4a7-08d7f6befeac
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 21:54:07.1389 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: H2YzQ0BYlr6GEzz4qlhTrziH2Pz2iM27u42e99EwoeWmM4g7Q+YepPRsrvP2atmRmS7S3IHdZ1y8LgKDkd1U2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0477
Archived-At: 
Subject: Re: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 21:54:11 -0000

--_000_MN2PR00MB06863577B5987174117A1B07F5BE0MN2PR00MB0686namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V29ya3MgZm9yIG1lDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBC
ZWhhbGYgT2YgQWFyb24gUGFyZWNraQ0KU2VudDogVHVlc2RheSwgTWF5IDEyLCAyMDIwIDI6NDQg
UE0NClRvOiBQaGlsbGlwIEh1bnQgPHBoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNvbT4NCkNjOiBP
QXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBJbmNvcnBv
cmF0ZSBvciBSZWZlcmVuY2UgUkZDODYyOCBEZXZpY2UgQXV0aG9yaXphdGlvbiBHcmFudD8NCg0K
SSBoYXZlIGEgZHJhZnQgSSdtIGFib3V0IHRvIHB1Ymxpc2ggYWZ0ZXIgb3VyIHJlY2VudCBkaXNj
dXNzaW9ucy4gT25lIG9mIHRoZSBjaGFuZ2VzIGlzIGFkZGluZyBhbiBhcHBlbmRpeCB0aGF0IGxp
c3RzIG91dCBhIGJ1bmNoIG9mIGV4aXN0aW5nIE9BdXRoIGV4dGVuc2lvbnMsIGFuZCB0aGUgZGV2
aWNlIGdyYW50IGlzIGluIHRoZXJlLiBJIGFsc28gcmVwbGFjZWQgdGhlICJFeHRlbnNpb24gR3Jh
bnRzIiBleGFtcGxlIGluIHNlY3Rpb24gNC4zIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtcGFyZWNraS1vYXV0aC12Mi0xLTAyI3NlY3Rpb24tNC4zKSB3aXRoIHRoZSBkZXZpY2Ug
Z3JhbnQgc2luY2UgdGhhdCBpcyBkZXBsb3llZCBmYXIgd2lkZXIgdGhhbiB0aGUgU0FNTCBBc3Nl
cnRpb24gZ3JhbnQgdGhhdCB3YXMgaW4gdGhhdCBleGFtcGxlIGluIFJGQzY3NDkuIFRoaXMgd2ls
bCBiZSBwdWJsaXNoZWQgYXMgdmVyc2lvbiAtMDMgaW4gdGhlIG5leHQgZmV3IGRheXMuIERvIHlv
dSB0aGluayB0aGF0IHdvdWxkIGJlIGVub3VnaD8NCg0KQWFyb24gUGFyZWNraQ0KDQoNCk9uIFR1
ZSwgTWF5IDEyLCAyMDIwIGF0IDI6MzkgUE0gUGhpbGxpcCBIdW50IDxwaGlsLmh1bnRAaW5kZXBl
bmRlbnRpZC5jb208bWFpbHRvOnBoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNvbT4+IHdyb3RlOg0K
T25lIG9mIHRoZSB1c2UgY2FzZXMgYnJvdWdodCB1cCBpbiB0aGUgUk9QQyB0aHJlYWQgbWVudGlv
bmVkIHRoYXQgcmVkaXJlY3Qgd2FzIGhhcmQgdG8gZG8gaW4gc29tZSBjYXNlcyAobGlrZSBJb1Qp
LiBUaGlzIHJlbWluZGVkIG1lIG9mIFJGQzg2MjgsIHRoZSBPQXV0aCBEZXZpY2UgQXV0aG9yaXph
dGlvbiBHcmFudC4gSSBtZW50aW9uIGl0IGJlY2F1c2UgZm9yICpzb21lKiBvZiB0aGUgY2FzZXMg
d2hvIHNheSByZWRpcmVjdGlvbiBpcyBoYXJkIG1heSBiZSBhYmxlIHRvIHVzZSB0aGUgRGV2aWNl
IEF1dGh6IEdyYW50Lg0KDQpXb3VsZCBpdCBiZSB3b3J0aCBpbmNsdWRpbmcgYSBzZWN0aW9uIGlu
IE9BdXRoIDIuMSByZWZlcmVuY2luZyBSRkM4NjI4IG9yLCBwb3NzaWJseSBpbmNvcnBvcmF0aW5n
IGl0Pw0KDQpQaGlsIEh1bnQNCkBpbmRlcGVuZGVudGlkDQpwaGlsLmh1bnRAaW5kZXBlbmRlbnRp
ZC5jb208bWFpbHRvOnBoaWwuaHVudEBpbmRlcGVuZGVudGlkLmNvbT4NCg0KDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

--_000_MN2PR00MB06863577B5987174117A1B07F5BE0MN2PR00MB0686namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47
DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7
cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48
IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0
PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5
b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Xb3JrcyBmb3IgbWU8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoICZs
dDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KQWFyb24g
UGFyZWNraTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTIsIDIwMjAgMjo0NCBQTTxi
cj4NCjxiPlRvOjwvYj4gUGhpbGxpcCBIdW50ICZsdDtwaGlsLmh1bnRAaW5kZXBlbmRlbnRpZC5j
b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEluY29ycG9yYXRlIG9yIFJlZmVyZW5j
ZSBSRkM4NjI4IERldmljZSBBdXRob3JpemF0aW9uIEdyYW50PzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBkcmFmdCBJJ20gYWJvdXQgdG8gcHVibGlzaCBh
ZnRlciBvdXIgcmVjZW50IGRpc2N1c3Npb25zLiBPbmUgb2YgdGhlIGNoYW5nZXMgaXMgYWRkaW5n
IGFuIGFwcGVuZGl4IHRoYXQgbGlzdHMgb3V0IGEgYnVuY2ggb2YgZXhpc3RpbmcgT0F1dGggZXh0
ZW5zaW9ucywgYW5kIHRoZSBkZXZpY2UgZ3JhbnQgaXMgaW4gdGhlcmUuIEkgYWxzbyByZXBsYWNl
ZCB0aGUgJnF1b3Q7RXh0ZW5zaW9uIEdyYW50cyZxdW90OyBleGFtcGxlDQogaW4gc2VjdGlvbiA0
LjMgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXJlY2tpLW9h
dXRoLXYyLTEtMDIjc2VjdGlvbi00LjMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1wYXJlY2tpLW9hdXRoLXYyLTEtMDIjc2VjdGlvbi00LjM8L2E+KSZuYnNwO3dpdGggdGhlIGRl
dmljZSBncmFudCBzaW5jZSB0aGF0IGlzIGRlcGxveWVkIGZhciB3aWRlciB0aGFuIHRoZSBTQU1M
IEFzc2VydGlvbiBncmFudCB0aGF0DQogd2FzIGluIHRoYXQgZXhhbXBsZSBpbiBSRkM2NzQ5LiBU
aGlzIHdpbGwgYmUgcHVibGlzaGVkJm5ic3A7YXMgdmVyc2lvbiAtMDMgaW4gdGhlIG5leHQgZmV3
IGRheXMuIERvIHlvdSB0aGluayB0aGF0IHdvdWxkIGJlIGVub3VnaD88bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uIFBhcmVja2k8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1heSAx
MiwgMjAyMCBhdCAyOjM5IFBNIFBoaWxsaXAgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwu
aHVudEBpbmRlcGVuZGVudGlkLmNvbSI+cGhpbC5odW50QGluZGVwZW5kZW50aWQuY29tPC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiB0aGUgdXNlIGNhc2VzIGJyb3VnaHQgdXAg
aW4gdGhlIFJPUEMgdGhyZWFkIG1lbnRpb25lZCB0aGF0IHJlZGlyZWN0IHdhcyBoYXJkIHRvIGRv
IGluIHNvbWUgY2FzZXMgKGxpa2UgSW9UKS4gVGhpcyByZW1pbmRlZCBtZSBvZiBSRkM8c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ODYyOCwgdGhlIE9BdXRoIERldmljZSBBdXRob3JpemF0
aW9uIEdyYW50LiBJIG1lbnRpb24gaXQgYmVjYXVzZSBmb3INCiAqc29tZSogb2YgdGhlIGNhc2Vz
IHdobyBzYXkgcmVkaXJlY3Rpb24gaXMgaGFyZCBtYXkgYmUgYWJsZSB0byB1c2UgdGhlIERldmlj
ZSBBdXRoeiBHcmFudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Xb3VsZCBp
dCBiZSB3b3J0aCBpbmNsdWRpbmcgYSBzZWN0aW9uIGluIE9BdXRoIDIuMSByZWZlcmVuY2luZyBS
RkM4NjI4IG9yLCBwb3NzaWJseSBpbmNvcnBvcmF0aW5nIGl0Pzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5QaGlsIEh1bnQ8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh
Y2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0i
X2JsYW5rIj5waGlsLmh1bnRAaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm
PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv
YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_MN2PR00MB06863577B5987174117A1B07F5BE0MN2PR00MB0686namp_--


From nobody Tue May 12 17:35:09 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C943A0CC0 for ; Tue, 12 May 2020 17:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level: 
X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2mL9oaHO9XF for ; Tue, 12 May 2020 17:35:05 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) (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 41C923A0CB4 for ; Tue, 12 May 2020 17:35:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.73,385,1583154000";  d="scan'208,217";a="364136051"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 13 May 2020 10:35:02 +1000
Received: from wsapp5863.srv.dir.telstra.com ([10.75.131.32]) by ipcbni.tcif.telstra.com.au with ESMTP; 13 May 2020 10:35:02 +1000
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5863.srv.dir.telstra.com (10.75.131.32) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 10:35:01 +1000
Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 13 May 2020 10:35:01 +1000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QCpOkjSk8gEBxMx5BpZ2EHGo44TazRKkJw0cSgc9Hy0S0+5j6bMreGggg4VE8urQ5Mvqxg1ILJRCCPMHDAqAXURJWQ7AR/DmvWqqAblBv2o8YnHG1aau+xb8pHo1Yw2iun4tenVuA/+T70E9r2ExQlj34xqBbny2qWkxrm9O/A4+RgLD+KGwcm6flTAeQMyFkxu6OsJcZscZmZn5Xl1nlLaFUTHX2vYnsq91F2PL81hy06gP8DYbFSS0riS464Vf0FzDHcQjctrEhcHzD8ootePOT83hXS8tG9sMRXnhVL805kVxY32pGrQH3/qGwX0dSN33LAy7y9jZ3vd3DigZIQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h12VQVyDx2peqSA0y9hzHYHVaXzrWN1kCBdQ8rNGWhI=; b=CG/GNqZLBxBRekj3mNTwTdkyUex7V3eZP5kpILNnkUq+6nZum7Q7rDlMdkGdQhXngBmL+W98dIzUAGTo1H7MpzZ4qsAb0u7Q9gWQRXPb9UVQAKqWc36mjqNAeBqrPcN+/hk+h0nFcRJb6yv+Jve6HCuYH3sZai+ywqULssYtILGWReeVAntNrYAk6gOt5f+5O9bqsmrN0+X8Flq+tTRgtspJmDJD+3na6TGFHInDFcnzxTAZT/ew6QdWcEgaIItyp78ymPxdFxhez9iG59FSHqAg9CCqML6nC0Dw5Bvm+JRhznFMwqlJB+OdV4T14VFSxSU1OVQk3/jYRQNNuSTrOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h12VQVyDx2peqSA0y9hzHYHVaXzrWN1kCBdQ8rNGWhI=; b=DlS70ovaPi8rZl56CuWCtx9wKJa1SYTjYB4UyGKPGPNnl+YGU8AakJZgZ7GxvZSRdyrJJEnaEBCPbX5x7PdH2l0F0BCvwXH82Vv9oFPyzmIDKZKklFDQyxoM4/K5k8wLnEIjG5H2vtux2eAdD46ab7qp5kkB0z3PUgB/VMLhPrM=
Received: from MEXPR01MB1702.ausprd01.prod.outlook.com (2603:10c6:200:16::7) by MEXPR01MB0647.ausprd01.prod.outlook.com (2603:10c6:200:1::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Wed, 13 May 2020 00:34:59 +0000
Received: from MEXPR01MB1702.ausprd01.prod.outlook.com ([fe80::4d7:1b54:6ee:bb6a]) by MEXPR01MB1702.ausprd01.prod.outlook.com ([fe80::4d7:1b54:6ee:bb6a%3]) with mapi id 15.20.3000.016; Wed, 13 May 2020 00:34:59 +0000
From: "Manger, James" 
To: Denis , Vittorio Bertocci 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AQHWE1gGZMyrQ8qcS0qZND1RXU6Qz6iQWrGAgAAd5wCAAQopAIAGCOCAgABNT4CABzkQAIAD6DkAgAAPooCAALboAIAAL3MAgAAoywCAAEcSAIAABu/QgAAnUoCAALHBcA==
Date: Wed, 13 May 2020 00:34:59 +0000
Message-ID: 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr>     <0c7942f8-f94b-f0a9-cec1-cfa9803d4db6@free.fr>  
In-Reply-To: 
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.1.100.23
dlp-reaction: no-action
authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=team.telstra.com;
x-originating-ip: [144.132.40.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 314baf6a-7f0d-435d-e94f-08d7f6d577e6
x-ms-traffictypediagnostic: MEXPR01MB0647:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0402872DA1
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mx184ge0KH+4lECxOGcsfZje4m4tgrZlxNSoyFEK0aTXs+fO8652ZivextpXESD7lqNt+eoXdGHnf9aYDN6l4giddtjPTzaCXv8S683zA1lOTNUanKrkoX9g86WXPpD2zb7+FjsTRsEHRQTJ2V6W0vusSUFpOdDZ9BRp3a3pF+yYRs1qP7I0tNB+C8DqxQ0TU7pPMVIGgHMAOuN11/Rze7RmuzJoUzZttcf2WN89M5Q9uHF+glctFhrJhjJQZnTZZA1EEvoxlSx9yJXz6jALGCNCnTZAjh6KRS0XmS/BT1UlJt12ebNZfjYZTUwJCxtwlBxP8KlAggb8XZ7jtB7KQ1mi5RJ4zMC3jqs7CxhSkb2sxhCuQYhmPVZ/aCL6bouJ+jepZP/LF+EIsMlL3OBNkL4+CnHR3Z7lZ7EI44ErpYnI7Y8LNfXy/gVNIAXM7Q3o9kaiH2iYsfgD/gJzz1rejJCJJlU2N7GheIavx9b6BpFJZFApJjXBOcj/FgJAFungJLp/oELTxYESgsA/ai1WChz/5fQiYUX8NV7vvVe7ErW23sxJq5iY50Cxf/242in4
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MEXPR01MB1702.ausprd01.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(33430700001)(76116006)(478600001)(53546011)(33656002)(186003)(6506007)(55016002)(7696005)(5660300002)(71200400001)(8676002)(2906002)(86362001)(8936002)(26005)(110136005)(52536014)(9686003)(4326008)(64756008)(66946007)(66476007)(33440700001)(316002)(66446008)(66556008)(15866825006); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: M/T38ozYq3HC08CaGoYkhVjSaluUDq1WTDNhXx9h/0DfRWdZTeEPBs1LHAGXmAqAGiRXvcJUe6tta7r0jxZvmMGWmL5S563gX3B2/+V1Nzahl0YxiydPfjz0RfMk2WYjQOeZhbfHRP+vQCYwM/AKLuid0IuhHo6JNSvTBF4N/+JnihacBJxI+iMFsFny/pD7+ul9H1LUoQ3puYlJLadj9XHLDtwIzS36jWBldgMa/CLeouBoM9cZfWKDSTv+2W9g4UQKyvIExMNvV9xrFO54dkhirGKGGAEgKWt3bpUzL90iYU6kQRUKYG0h/HGNuM0z7+a98sBijdM0BiEaCeM3kgn4Ly7m1uvXlpXe3UZLL33E+DhuxienTODkyGaKNnAsVgh2j+KTnKvZth0sMAJHkWSDDA1oDTnVJ4ldzm4krSVDmrOkMZNy45CYpC1wRNBk3URL0wP9XhRyyr0opiH1kw6otln+jH6FrAwF4g89rJg=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MEXPR01MB17029BA84DD7161D89D8D1B6E5BF0MEXPR01MB1702ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 314baf6a-7f0d-435d-e94f-08d7f6d577e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 00:34:59.5173 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QKQ0arq7AuFzbGkWLjq5oMGarWnCFAK1CHioQnzw3IQABVTbIS5U+4t+v3epJ7ZrRQm0Rxplb5d+bKh/pPG34u5ZOrhq6TTy77ZUQ8vJmYM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB0647
X-OriginatorOrg: team.telstra.com
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 00:35:08 -0000

--_000_MEXPR01MB17029BA84DD7161D89D8D1B6E5BF0MEXPR01MB1702ausp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That text is a worse suggestion. It hopelessly confuses "end-user" and "cli=
ent".

The idea behind the text is only relevant to a client that is written to ca=
ll a resource server and is registered with an authorization server, but th=
inks that the details those two exchange (via access tokens) at the client'=
s instigation are sometimes fine, yet at other times are a privacy violatio=
n that they aren't trying to hide. It is theoretically conceivable that the=
re is a niche where that is possible, which shows how flexible OAuth is.

I think the main message of this thread is that an access-token really shou=
ld be explicitly made opaque (by being a reference, or an encrypted JWT) to=
 avoid the privacy risk that details intended to be shared between an Autho=
rization Server and Resource Server are leaked to a Client.

End-users with privacy concerns (which is all of us) should carefully choos=
e the Authorization Servers we deal with. Here is an alternative suggestion=
 as an OAuth privacy consideration.

"OAuth is used to convey information established at an Authorization Server=
 to a Resource Server. Only those two parties - and not the End-User nor th=
e Client - can be sure of knowing the extent of that information. More End-=
User control would require a different style of protocol than OAuth, such a=
s self-sovereign identity."

--
James Manger

From: Denis 
Sent: Tuesday, 12 May 2020 10:40 PM
To: Manger, James ; Vittorio Bertocci 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"

[External Email] This email was sent from outside the organisation - be cau=
tious, particularly with links and attachments.
Hi James,

You wrote: "Because your client has violated a MUST in the best practices".=
 It seems that you are already taking your wish as granted.
However, this is exactly the point we are discussing.

You wrote: "The end-user has to trust the Authorization Server (they sign-i=
n there)". The end-user does not trust the AS for everything,
but only with respect to some activities. Please remember a definition of t=
rust present in ISO/IEC 13888-1. 3.59.
trust : relationship between two elements, a set of activities and a securi=
ty policy in which element x trusts element y
if and only if x has confidence that y will behave in a well defined way (w=
ith respect to the activities) that does not violate
the given security policy.
You wrote: "The access-token might be a JWT with minimal claims". Yes indee=
d, however the end-user may not know it.

You wrote  "a client to do that inspection as standard behaviour". No, toke=
n inspection is not a standard behaviour.
It happens if, and only if, the end-user has some privacy concerns. Please =
reconsider the text proposal which does make
that point:
   There are however cases, where the access token content presents privacy=
 issues for a given scenario. In such cases,
   the end-user would like to know which attributes have been placed in a t=
oken before forwarding it to a resource server.
   If these attributes do not correspond to the expectations of the end-use=
r or if the format of the access token is not understandable
   by the client, then the client SHOULD NOT forward the access token to th=
e resource server.

Denis

That text is an poor suggestion, Denis.

> end-user will usually have no knowledge of the attributes which correspon=
d to the scope

The OAuth model is that the Authorization Server is responsible for informi=
ng the end-user about what is going on. That's why they display consent pag=
es showing what will be disclosed, often giving the end-user control over t=
his.

> the end-user would like to know which attributes have been placed in a to=
ken ...
> ... if the format of the access token is not understandable by the client=
, then the client SHOULD NOT forward

A major point of OAuth is to protect end-users from clients. The end-user h=
as to trust the Authorization Server (they sign-in there), but that can les=
sen the trust required in clients.

A client that inspects an access-token in the hope of preventing an Authori=
zation Server from disclosing too much to a Resource Server is kidding itse=
lf (and kidding the end-user). The access-token might be a JWT with minimal=
 claims, then the RS calls the AS's token-inspection API and gets back squi=
llions of claims.

So, by all means, do some auditing of Authorization Servers, Resource Serve=
rs, and the tokens they exchange to improve your confidence that they are b=
ehaving as they say. But if you write a client to do that inspection as sta=
ndard behaviour then don't call it OAuth-compliant. It will break when the =
Authorization Server choses to change its token format. Because your client=
 has violated a MUST in the best practices it will be clear where the respo=
nsibility for broken interop lies. And the rest of the ecosystem can hope t=
hat such clients are not prevalent enough to harm ongoing evolution of the =
rest of the system.

--
James Manger

From: OAuth  On Beha=
lf Of Denis
Sent: Tuesday, 12 May 2020 7:55 PM
To: Vittorio Bertocci 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"
...
This being stated, hereafter is a full text proposal replacement for the fi=
rst paragraph (12 lines)
of the Privacy Considerations section (section 6):

    As indicated in RFC 6750, the "scope" value is intended for programmati=
c use and is not meant to be displayed to end-users.
   This means that, even when the client uses the scope parameter, the end-=
user will usually have no knowledge of the attributes
   which correspond to the scope (or to a missing scope parameter).

   RFC 6749 mentions that the string [access token] is usually opaque to th=
e client. Hence, the client will not necessarily be able
   to inspect the content of the access token. As an example, an authorizat=
ion server and a resource server might decide to change
   the access token format at any time.

   There are however cases, where the access token content presents privacy=
 issues for a given scenario. In such cases,
   the end-user would like to know which attributes have been placed in a t=
oken before forwarding it to a resource server.
   If these attributes do not correspond to the expectations of the end-use=
r or if the format of the access token is not understandable
   by the client, then the client SHOULD NOT forward the access token to th=
e resource server.
Denis







--_000_MEXPR01MB17029BA84DD7161D89D8D1B6E5BF0MEXPR01MB1702ausp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











That text=
 is a worse suggestion. It hopelessly confuses “end-user” and &=
#8220;client”.


&nbs=
p;


The idea =
behind the text is only relevant to a client that is written to call a reso=
urce server and is registered with an authorization server, but thinks that=
 the details those two exchange (via
 access tokens) at the client’s instigation are sometimes fine, yet a=
t other times are a privacy violation that they aren’t trying to hide=
. It is theoretically conceivable that there is a niche where that is possi=
ble, which shows how flexible OAuth is.


&nbs=
p;


I think t=
he main message of this thread is that an access-token really should be exp=
licitly made opaque (by being a reference, or an encrypted JWT) to avoid th=
e privacy risk that details intended
 to be shared between an Authorization Server and Resource Server are leake=
d to a Client.


&nbs=
p;


End-users=
 with privacy concerns (which is all of us) should carefully choose the Aut=
horization Servers we deal with. Here is an alternative suggestion as an OA=
uth privacy consideration.


&nbs=
p;


“OAuth is used to convey information established =
at an Authorization Server to a Resource Server. Only those two parties =
211; and not the End-User nor the Client – can be
 sure of knowing the extent of that information. More End-User control woul=
d require a different style of protocol than OAuth, such as self-sovereign =
identity.”


&nbs=
p;




--


James Manger




&nbs=
p;






From: Denis <denis.ietf@free.fr>


Sent: Tuesday, 12 May 2020 10:40 PM

To: Manger, James <James.H.Manger@team.telstra.com>; Vittorio =
Bertocci <vittorio.bertocci@auth0.com>

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






 












[External Email] This email was sent from outside the organisat=
ion – be cautious, particularly with links and attachments.














Hi James,






 






You wrote: 
"Because your client has violated a MUST in the best practice=
s". It seems that you are already taking your wish as granted.


However, this is exactly the point we are discussing.






 






You wrote: "The end-user has to trust =
the Authorization Server (they sign-in there)". The end-user does not =
trust the AS for everything,


but only with respect to some activities. Please remember a definition of t=
rust present in ISO/IEC 13888-1. 3.59.








trust : relationship between two elements, =
a set of activities and a security policy in which element x trusts element=
 y


if and only if x has confidence that y will behave in a well defined way (w=
ith respect to the activities) that does not vio­late


the given security policy.




You wrote: "The access-token might be a JWT with =
minimal claims". Yes indeed, however the end-user may not know
 it.








 






You wrote  "a=
 client to do that inspection as standard behaviour". No, token inspec=
tion
 is not a standard behaviour. 

It happens if, and only if, the end-user has some privacy concerns. Please =
reconsider the text proposal which does make


that point:






   There are however cases, where the access token content p=
resents privacy issues for a given scenario. In such cases,


   the end-user would like to know which attributes have been pla=
ced in a token before forwarding it to a resource server.


   If these attributes do not correspond to the expectations of t=
he end-user or if the format of the access token is not understandable


   by the client, then the client SHOULD NOT forward the access t=
oken to the resource server.






 






Denis






 








That text=
 is an poor suggestion, Denis.


 


> =
end-user will usually have no knowledge of the attributes which correspond =
to the scope


 


The OAuth model is that the Authorization Server is res=
ponsible for informing the end-user about what is going on. That’s wh=
y they display consent pages showing what will be disclosed,
 often giving the end-user control over this.


 


> the
end-user would like to know which attributes have been placed in a t=
oken …


> … if the format of the access token is not u=
nderstandable by the
client, then the client SHOULD NOT forward


 


A major p=
oint of OAuth is to protect end-users from clients. The end-user has to tru=
st the Authorization Server (they sign-in there), but that can lessen the t=
rust required in clients.


 


A client =
that inspects an access-token in the hope of preventing an Authorization Se=
rver from disclosing too much to a Resource Server is kidding itself (and k=
idding the end-user). The access-token
 might be a JWT with minimal claims, then the RS calls the AS’s token=
-inspection API and gets back squillions of claims.


 


So, by al=
l means, do some auditing of Authorization Servers, Resource Servers, and t=
he tokens they exchange to improve your confidence that they are behaving a=
s they say. But if you write a client
 to do that inspection as standard behaviour then don’t call it OAuth=
-compliant. It will break when the Authorization Server choses to change it=
s token format. Because your client has violated a MUST in the best practic=
es it will be clear where the responsibility
 for broken interop lies. And the rest of the ecosystem can hope that such =
clients are not prevalent enough to harm ongoing evolution of the rest of t=
he system.


 




--


James Manger




 






From: OAuth
<oauth-bounces@ietf.org> On Behalf Of
Denis

Sent: Tuesday, 12 May 2020 7:55 PM

To: Vittorio Bertocci <vittorio.bertocci@auth0.com>

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






…






This being stated, hereafter is a full text proposal replacement for =
the first paragraph (12 lines)


of the Privacy Considerations section (section 6):


 


=
    As indicated in RFC 6750, the "scope" value is=
 intended for programmatic use and is not meant to be displayed to end-user=
s.

   This means that, even when the client uses the scope parameter=
, the end-user will usually have no knowledge of the attributes


&nb=
sp;  which correspond to the scope (or to a missing scope parameter).




&nb=
sp;  RFC 6749 mentions that the string [access token] is usually opaqu=
e to the client. Hence, the client will not necessarily be able


&nb=
sp;  to inspect the content of the access token. As an example, an aut=
horization server and a resource server might decide to change


   the access token format at any time.



&nb=
sp;  There are however cases, where the access token content presents =
privacy issues for a given scenario. In such cases,


   the end-user would like to know which attributes have been pla=
ced in a token before forwarding it to a resource server.


   If these attributes do not correspond to the expectations of t=
he end-user or if the format of the access token is not understandable


   by the client, then the client SHOULD NOT forward the access t=
oken to the resource server.


Denis










 






 








--_000_MEXPR01MB17029BA84DD7161D89D8D1B6E5BF0MEXPR01MB1702ausp_--


From nobody Tue May 12 20:16:01 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596363A07B6 for ; Tue, 12 May 2020 20:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: 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-2WEjt0IPpJ for ; Tue, 12 May 2020 20:15:58 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79C63A0484 for ; Tue, 12 May 2020 20:15:57 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id d207so7820029wmd.0 for ; Tue, 12 May 2020 20:15:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eAScNggKAIM6iwkhgY8la76TAuUgyWF2kuPT9BqPlyI=; b=e360xwIknfj2rgYRjGqzMUQF3UVZvB47gmO1H6tVM4Ev794/qqn1UchQuOYDg0Wqhb ZutpwK0YlNYmvbjySN1RMWW/+laHwTXkV3IYxxchK1LHlnnW6DCH49nXcdjLmOvo055W hwDdmUpUl6LfDIWdqNZmoeRHY6HUZKAZxMzTc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eAScNggKAIM6iwkhgY8la76TAuUgyWF2kuPT9BqPlyI=; b=ESPOHIaYzrGrf2ibZQgTa53cmPOtOS/AthHN4vQKqrJ5tVtf5YE3N5kXMNCuLzjefI 63J4tFKiOozYCxu1N6YnStrdqR5eVHuoS8TQVFd3i8LZwtpuF9KdkKhoy3u1pTbcB3zL Pzdc1QkcdtB/1aHe/1eBjFCSWY+TW9r0dQZSFBZddocONG+EIJVvXWn7q/JFbRkHVAOy G2TY0XIO5WdE0mD55P65DKS5ZOz+X/QJAlNPs9RjtttIQBiGvwBTsQ8zjLh7YF5PwLjS HZueCsYUfqw7lFDhiiaNm93UdsQgwFjSZL2mjp4VDUb8pavjddIZY1tRmAHzXLTVktnk 082A==
X-Gm-Message-State: AOAM5331Phcc4Megs6oTtttnrqd1DKm0ecBy6FLSJpgyXzsoGL0q84uS 22BC/88YpEhXilWopcucIB/zEMarPhtcIfxohS/ZpLLa2F67yw==
X-Google-Smtp-Source: ABdhPJxCPnc5jP5yJUnJavalQ/NWj34RVnmKT30a8+20AKgtNrOwH5W6DnedSS4+MIaaSTU2JmtNP+SgVkrbyZLzRdo=
X-Received: by 2002:a1c:5985:: with SMTP id n127mr684436wmb.64.1589339755782;  Tue, 12 May 2020 20:15:55 -0700 (PDT)
MIME-Version: 1.0
References:  <77C31557-E3C3-4A02-9579-DEFB2CD5A683@manicode.com>   <94617b561b934791933f171f5baa51cb@novatec-gmbh.de>
In-Reply-To: <94617b561b934791933f171f5baa51cb@novatec-gmbh.de>
From: Francis Pouatcha 
Date: Tue, 12 May 2020 23:15:44 -0400
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000923c0305a57eff3a"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 03:16:00 -0000

--000000000000923c0305a57eff3a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The draft  draft-parecki-oauth-v2-1-02 mentions in the abstract:
"This specification replaces and obsoletes the OAuth 2.0
Authorization Framework described in RFC 6749."  Believe me we will witness
a lot of client calls asking for the replacement of ROPC  flows.

There is no way we can omit ROPC without providing an equivalent
alternative (From the perspective of simplicity). Even with the exact match
of redirect-uri included in oAuth-2.1, there is still a lot of hazard
associated with redirection on a user controlled device. The security BCP
(draft-ietf-oauth-security-topics-15) is still far from covering all use
cases as there are too many parameters involved in the redirection thread
models, as redirect-uri travel  through client devices, as client device
operating system decides which url get forwarded to which user agent, as
user default web browser might change in the course of a redirection flow,
...

The only really secure relationship between a user agent and a server is a
one  time established connection in which the user (RO) in control of
that user agent instance can prove ownership of some credentials without
leaving the context of the loaded application loaded by that user agent. In
oAuth2.0 this behavior is only guaranteed by the ROPC flow (Client
credential flow not being considered an end user flow). Each flow requiring
redirection leads to offloading and reloading of the application context of
the resource owner in the target user agent. User device configuration
might lead to reload in a different user agent leading to more confusion.

RFC8628 does not solve the problem. Once again, it is essential to
distinguish between an oAuth Client and a resource owner (RO). Resource
owner authorization flows can not be replaced by oAuth client
authorizations flows. Even if the oAuth Client runs on the user devices. It
is essential from AS to distinguish between client credentials  and
resource owner credentials, else we will break a lot of authorization
models out there.

As we do not have an equivalent alternative for ROPC, we have to raise the
attention of  implementers by mentioning that ROPC  must only be used if
AS / oAuth Client can guarantee security of the RO credentials exposed to
the oAuth Client. Without this, oAuth2.1 can not be a replacement of
oAuth2.0 but just a security BCP.

Related Topic:
We can have a better theoretical analysis of redirection thread models, if
oAuth2.1 includes draft-ietf-oauth-par-01. As this will solidify
redirection based approaches by limiting the quantity of information pushed
by oAuth Client over client devices to AS.

The oAuth2.1 as presented now is still not secure enough to replace
oAuth2.0-ROPX and not secure enough to be accepted in some critical
environments. In order to increase acceptance:
- Include ROPC  with provision/warning on sharing RO password with oAuth
Client.
- Include PAR to solidify redirection based flow.

On Tue, May 12, 2020 at 3:50 PM Falk Andreas 
wrote:

> > Keep in mind that while the Security BCP explicitly forbids the use of
> the Password grant in OAuth 2.0, technically OAuth 2.1 just never include=
s
> it in the first place. Subtle difference.
>
>
> As RFC 6749 clearly targets third-party applications, ROPC never has been
> a good fit.  It always felt like a bad workaround just for legacy
> applications.
>
>
> I am primarily looking at OAuth 2.1 from a developer's perspective.
> Unfortunately, developers often look for a shortcut and the easiest way t=
o
> implement a required use case.
>
> You can find many entries on StackOverflow directing developers to use
> ROPC instead of a "complicated" redirection flow.
>
> Frameworks like Spring Security or Angular clearly follow a "secure by
> default" approach, this may also be a good direction to follow in future
> specifications.
>
>
> As Jim already pointed out, I also consider the ROPC being an
> authentication flow (for trusted first-party applications) and this use
> case is covered by OIDC.
>
>
> Same as for PKCE an AS may still provide ROPC in an OAuth 2.0
> compatibility mode to not break existing apps.
>
>
> That is why I support OAuth 2.1 omitting ROPC.
>
>
> Andreas Falk
>
> ------------------------------
> *From:* OAuth  on behalf of Aaron Parecki <
> aaron@parecki.com>
> *Sent:* 12 May 2020 20:19
> *To:* Francis Pouatcha
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
>
> > We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1
> forbidding the user of ROPC.
>
> Keep in mind that while the Security BCP explicitly forbids the use of th=
e
> Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it
> in the first place. Subtle difference.
>
> Aaron Parecki
>
>
> On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha  40adorsys.de@dmarc.ietf.org> wrote:
>
>>
>>
>> On Tue, May 12, 2020 at 9:50 AM Jim Manico  wrote:
>>
>>> Forgive me if this question is late or poor context, but wouldn=E2=80=
=99t OIDC
>>> be a better replacement for ROPC since it=E2=80=99s essentially a authe=
ntication
>>> flow?
>>>
>>> What use case for ROPC mandates OAuth2 over OIDC?
>>>
>> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1
>> forbidding the user of ROPC.
>>
>>
>>> --
>>> Jim Manico
>>> @Manicode
>>>
>>> On May 11, 2020, at 11:00 PM, Francis Pouatcha >> 40adorsys.de@dmarc.ietf.org> wrote:
>>>
>>> =EF=BB=BF
>>> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner
>>> Password Credentials) with the following reasoning:
>>>
>>> Auth Code Grant:
>>> There are  many use cases on the market where redirection based flows d=
o
>>> not work.. As  we see in the "OAuth 2.1 - require PKCE?" thread, the
>>> complexity of user agents on non controllable client devices still make
>>> user agent redirection a challenge.
>>>
>>> Client Credentials Grant:
>>> Requires the registration of an oAuth client.
>>> - Citing the iot device use cases Beena which do not have a comfortable
>>> way to have iot devices register with AS.
>>> - This is a registration flow for the oAuth client role  and for the RO
>>> (Resource Owner). Remember resource owner credentials might be sourced =
from
>>> system external to the AS  like company's LDAP. oAuth Client Credential=
s
>>> are generally managed by the AS.
>>> For these reasons, we shall not use Client Credential Grant to manage R=
O
>>> authorization.
>>>
>>> ROPC:
>>> Having an oAuth Client proxy the auth request of the RO to the AS only
>>> presents a security risk if the oAuth Client is a third party applicati=
on.
>>> Therefore, the decision on whether to accept ROPC for a specified clien=
t
>>> shall be left to the AS. Discarding this use case will take a lot of
>>> business from oAuth servers back to the old market.
>>>
>>> Beside this, I mentioned in my previous post that there are use cases i=
n
>>> the market where permanent passwords are replaced with one time passwor=
ds.
>>>
>>> A lot of work is also being done in the direction of having the RO send
>>> signed proof of ownership to the AS through the ROPC  flow using the
>>> password field.
>>>
>>> Therefore, I am ok with raising the attention of  implementers the same
>>> way we are doing with PKCE,  mentioning that ROPC  must only be used if=
  AS
>>> / oAuth Client can guarantee security of the RO credentials exposed to =
the
>>> oAuth Client.
>>>
>>> /Francis
>>> --
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead at adorys
>>> https://adorsys-platform.de/solutions/
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--=20
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

--000000000000923c0305a57eff3a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The draft=C2=A0 draft-parecki-oauth-v2-1-02 mentions in th=
e abstract: "This=C2=A0specification replaces and obsoletes the OAuth =
2.0 Authorization=C2=A0Framework described in RFC 6749."=C2=A0 Believe=
 me we will witness a lot of client calls asking for the replacement of ROP=
C=C2=A0 flows.

There is no way we can omit ROPC without =
providing an equivalent alternative (From the perspective of simplicity). E=
ven with the exact match of redirect-uri included in oAuth-2.1, there is st=
ill a lot of hazard associated with redirection on a user controlled device=
. The security BCP (draft-ietf-oauth-security-topics-15) is still far from =
covering all use cases as there are too many parameters involved in the red=
irection thread models, as redirect-uri travel=C2=A0 through client devices=
, as client device operating system decides which url get forwarded to whic=
h user agent, as user default web browser might change in the course of a r=
edirection flow, ...

The only really secure relati=
onship between a user agent and a server is a one=C2=A0 time established co=
nnection in which the user (RO) in control of that=C2=A0user agent instance=
 can prove ownership of some credentials without leaving the context of the=
 loaded application loaded by that user agent. In oAuth2.0 this behavior is=
 only guaranteed by the ROPC flow (Client credential flow not being conside=
red an=C2=A0end user flow). Each flow requiring redirection leads to offloa=
ding and reloading=C2=A0of the application context of the resource owner in=
 the target user agent. User device configuration=C2=A0 might lead to=C2=A0=
reload in a different user agent leading to more confusion.=C2=A0=C2=A0
=


RFC8628 does not solve the problem. Once again, i=
t is essential to distinguish between an oAuth Client and a resource owner =
(RO). Resource owner authorization flows can not be replaced by oAuth clien=
t authorizations flows. Even=C2=A0if the oAuth Client runs on the user devi=
ces. It is essential from AS to distinguish between client credentials=C2=
=A0 and resource owner credentials, else we will break a lot of authorizati=
on models out there.

As we do not have an equi=
valent alternative for ROPC, we have to raise the attention of=C2=A0 implem=
enters by mentioning that ROPC=C2=A0 must only be used if=C2=A0 AS / oAuth =
Client can guarantee security of the RO credentials exposed to the oAuth Cl=
ient. Without this, oAuth2.1 can not be a replacement of oAuth2.0 but just =
a security BCP.

Related Topic:
=

We can have a better=C2=A0theoretical analysis of=C2=A0redirection thr=
ead models, if oAuth2.1 includes draft-ietf-oauth-par-01. As this will soli=
dify redirection based approaches by limiting the quantity of information p=
ushed by oAuth Client over client devices to AS.

=

The oAuth2.1 as presented now is still not secure enough=C2=A0to repla=
ce oAuth2.0-ROPX and not secure enough=C2=A0to be accepted in some critical=
 environments. In order to increase acceptance:
- Include ROPC=C2=
=A0 with provision/warning on sharing RO password with oAuth Client.
<=
div>- Include PAR to solidify redirection based flow.

On Tue, May 12, 2020 at 3:50 PM Falk Andreas <Andreas.Falk@novatec-gmbh.de> wrote:










>=C2=A0Keep in mind that while the Security BCP explicitly forbids
 the use of the Password grant in OAuth 2.0, technically=C2=A0OAuth 2.1 jus=
t never includes it in the first place. Subtle difference.







As RFC 6749=C2=A0clearly targets third-party applications, ROPC never
 has been a good fit.=C2=A0 It=C2=A0always felt like a bad workaround just =
for legacy applications.







I am primarily looking at OAuth 2.1 from=C2=A0a
 developer's perspective. Unfortunately, developers often look for a sh=
ortcut and the easiest way to implement a required use case.=C2=A0

You can find many=C2=A0entries on StackOv=
erflow directing developers to use ROPC instead of a "complicated"=
; redirection flow.


Frameworks like Spring Security or Angula=
r clearly follow a "secure by default" approach, this may also be=
 a good direction to follow in future specifications.=C2=A0







As Jim already=C2=A0pointed out, I also=
=C2=A0consider the ROPC being an authentication flow (for trusted=C2=A0firs=
t-party applications) and this use case=C2=A0is covered by OIDC.







Same as for=C2=A0PKCE=C2=A0an AS may=C2=
=A0still provide ROPC in an=C2=A0OAuth 2.0 compatibility mode to not break =
existing apps.=C2=A0










That is why=C2=A0I support OAuth 2.1 omitting=C2=A0ROPC.









Andreas Falk











From=
: OAuth <oauth-bounces@ietf.org> on behalf of Aaron Parecki <aaron@parecki.com>

Sent: 12 May 2020 20:19

To: Francis Pouatcha

Cc: OAuth WG

Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

=C2=A0








>=C2=A0We are not talking about ROPC mandating=C2=A0=C2=
=A0OAuth2, but about=C2=A0OAuth-2.1 forbidding=C2=A0the user of ROPC.







Keep in mind that while the Security BCP explicitly forbids the use of=
 the Password grant in OAuth 2.0, technically=C2=A0OAuth 2.1 just never inc=
ludes it in the first place. Subtle difference.







Aaron Parecki











On Tue, May 12, 2020 at 10:23 AM Fran=
cis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

















On Tue, May 12, 2020 at 9:50 AM Jim M=
anico <jim@manicod=
e.com> wrote:






Forgive me if this question is late or poor context, but =
wouldn=E2=80=99t OIDC be a better replacement for ROPC since it=E2=80=99s e=
ssentially a authentication flow?






What use case for ROPC mandates OAuth2 over OIDC?






We are not talking about ROPC mandating=C2=A0=C2=A0OAuth2, but about=
=C2=A0OAuth-2.1 forbidding=C2=A0the user of ROPC.
















--


Jim Manico


@Manicode







On May 11, 2020, at 11:00 PM, Francis Pouatcha &l=
t;fpo=3D40=
adorsys.de@dmarc.ietf.org> wrote:










=EF=BB=BF





I am against=C2=A0OAuth 2.1 discarding the use of ROPC (Re=
source Owner Password Credentials) with the following=C2=A0reasoning:







Auth Code Grant:


There are=C2=A0 many use cases on the market where redirec=
tion based flows=C2=A0do not work.. As=C2=A0 we see in the "OAuth 2.1 =
- require PKCE?" thread, the complexity of user agents on non controll=
able=C2=A0client devices still make user agent redirection a challenge.=C2=
=A0







Client Credentials Grant:


Requires the registration of an oAuth client.


- Citing the iot device use cases Beena which do not have =
a comfortable way to have iot devices register with AS.


- This is a registration flow for the oAuth client role=C2=A0 and for =
the RO (Resource Owner). Remember resource owner credentials might be sourc=
ed from system external to the AS=C2=A0 like company's LDAP. oAuth Clie=
nt Credentials are generally=C2=A0managed by the AS.


For these reasons, we shall not use Client Credential Grant to manage =
RO authorization.







ROPC:


Having an oAuth Client proxy the auth request of the RO to the AS only=
 presents a security risk if the oAuth Client is a third party application.=
 Therefore, the decision on whether to accept=C2=A0ROPC for a specified cli=
ent shall be left to the AS. Discarding
 this use case will take a lot of business from oAuth servers back to the o=
ld market.







Beside this, I mentioned in my previous post that there are use cases =
in the market where permanent passwords are replaced with one time password=
s.







A lot of work is also being done in the direction of having the RO sen=
d signed proof of ownership to the AS through the ROPC=C2=A0 flow using the=
 password field.











Therefore, I am ok with raising the attention of=C2=A0 implementers=C2=
=A0the same way we are doing with PKCE,=C2=A0 mentioning that ROPC=C2=A0 mu=
st only be used if=C2=A0 AS / oAuth Client can guarantee security of the RO=
 credentials exposed to the oAuth Client.=C2=A0







/Francis





-- 




















Francis Pouatcha


Co-Founder and Technical Lead at adorys


























_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




















-- 




















Francis Pouatcha


Co-Founder and Technical Lead at adorys






















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



















-- 
Francis Pouatcha
Co-=
Founder and Technical Lead at adorys


--000000000000923c0305a57eff3a--


From nobody Tue May 12 22:51:43 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186733A0DC2 for ; Tue, 12 May 2020 22:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWGxVUkFboYe for ; Tue, 12 May 2020 22:51:34 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9DC3A0DBE for ; Tue, 12 May 2020 22:51:34 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id l11so13245920wru.0 for ; Tue, 12 May 2020 22:51:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4veNQ7xTqjm3hRk5yGgIo8MoZNsjMm0y5bBm4ca/MJo=; b=gOTXRFbrZqabhlQnP87LG62hFkKlJKhS7HenIWvgsSl4GsDSqMKXWdRbCzdp1bfsD9 tGl+57/F2VNvI/ZuB5sLTQj0IqXOq+Y9woUKYkHqlmiTag19aJb7qP3oXhEb+7qC8zgU z1F0WuDTPh4jMo8ePD533QUNVHDrrMQKmI9O+/n/cC8uFF/qmWD0DuAPl+iDz7wLf/8T L3wk0FblFwaCWdX8XRC9k+naSialElXLFIjISlalsjN2cEsa46rvE8FopgKTwFEuXc4D uz+WnLU3j2IkFjkG9M1AKvtzwWvTGrFQ0KGM05U5LYqdV9b1O4VCV2AsPytJkMzWQWq0 DR9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4veNQ7xTqjm3hRk5yGgIo8MoZNsjMm0y5bBm4ca/MJo=; b=DxpU8AExXjADpmH3XPa7gUwxq1kBZoJdQfdjDkH3s1F7XVf+He/hpjOzY3bvTKRCFF 4UytPJFJkuMwfhFptPV+btXRjMXuSH4gHlcB9TysfaFGsM18ElPMsmDl63iaW2dhFZ40 y6fd1q3qVlj0bBs+Sqqt3gPX5yClXq9ZCB6aCZ7a4qhFfHoVOqN8n8p8nGo8wqKcOua8 Gxpzj9l6Q3hR2hhon3nL5xqQHOcMIWKEqv9SbJzUcFDvq8mflj/s+H5PQi3dCUEMHpq/ VtaIS53MiRw/E6llov/2IrYhZdggZcpMfoSGQe/GTL2t/ej2KfjeN4kckqODIMsO2uq3 lPjA==
X-Gm-Message-State: AGi0Pubn+qwouwRH7RDqhTebOUEZiFZikLT1C3VOPPeX3eS+EgN1Hkap cayJnR9Ri0/WMKBj/MIVfpBYsuSxRaulvV3n4BM=
X-Google-Smtp-Source: APiQypIUdv1N+YFbKQUaU3A1al88LrT4hWTU9X4U7KzL4xa5ADmxFm06Au8VoPf288i093DiQVblywysyBDBOaTv8XU=
X-Received: by 2002:a05:6000:1150:: with SMTP id d16mr21219035wrx.197.1589349092776;  Tue, 12 May 2020 22:51:32 -0700 (PDT)
MIME-Version: 1.0
References: <158608868945.18323.557347538112056951@ietfa.amsl.com> <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr>   <18e38735-ae9f-c41b-0cda-b2818a1038dc@danielfett.de> <7c27543f-6d14-2a5c-8a00-8b7d5baf17b1@free.fr>
In-Reply-To: <7c27543f-6d14-2a5c-8a00-8b7d5baf17b1@free.fr>
From: Janak Amarasena 
Date: Wed, 13 May 2020 11:20:56 +0530
Message-ID: 
To: Denis 
Cc: oauth , Daniel Fett ,  Vittorio Bertocci 
Content-Type: multipart/alternative; boundary="000000000000195d6b05a5812c65"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 05:51:40 -0000

--000000000000195d6b05a5812c65
Content-Type: text/plain; charset="UTF-8"

Hi All,

In section *4.1.3. Countermeasures
*
related to *4.1.  Insufficient Redirect URI Validation* it states

   The complexity of implementing and managing pattern matching
   correctly obviously causes security issues.  This document therefore
   advises to simplify the required logic and configuration by using
   exact redirect URI matching only.  This means the authorization
   server MUST compare the two URIs using simple string comparison as
   defined in [RFC3986], Section 6.2.1
.


Does this mean that the authorisation server MUST NOT use pattern matching
at all and MUST do simple string comparison for redirect URI?
If that is the case can we change the wording a bit in this section as
having "...therefore *advises* to simplify the required logic..." gives the
impression that the AS has the choice to decide whether or not to use
pattern matching. And then when we have "...authorization server *MUST*
compare the two URIs using simple string..." give the impression that the
AS should absolutely not(MUST NOT) use pattern matching.

Best Regards,
Janak Amarasena

On Fri, May 8, 2020 at 2:53 PM Denis  wrote:

> Hi Daniel,
>
> Thank you for pointing to your dissertation which has the following title
> : An Expressive Formal Model of the Web Infrastructure.
>
> Since it is 240 pages long (or thick), I have not read everything but some
> sentences brought my attention.
>
> I have experienced formal models in the past and everything depends upon
> the hypothesis that are made upfront.
>
> On page 28:
>
> 1.1.1. The Web Infrastructure Model
>
> (...)
> Altogether, the model is the *most comprehensive and detailed model for
> the web infrastructure to date* [i.e. in year 2018].
> (...)
>
> On page 40, there is the following sentence:
>
> *A browser is thought to be used by one honest user*, who is modeled as
> part of the browser.
>
>
> With such an hypothesis, it is impossible to consider a collusion attack
> between clients, hence the Model omits to consider such a case.
> When using a formal approach, it is generally not possible to make sure
> that all attacks have been considered, but when considering
> specific attacks, it is possible to demonstrate that they can be countered
> (or not).
>
> Many models are considering "adversaries". This originates from the
> "Alice, Bob and Carol model" where both Alice and Bob
> were honest and where Carol was the attacker. In the case of the "Alice
> and Bob Collusion attack", Alice and Bob are good friends.
> The target of the attack is a RS. The RS is not an adversary : it does
> nothing bad. Alice and Bob are adversaries towards Carol (the RS).
> This can bee seen as the revenge of "Alice and Bob" against Carol.  :-)
>
> On page 29, the text states:
>
> Model of OAuth 2.0
>
> Using our generic web model, we build a formal model of OAuth, closely
> following the OAuth 2.0 standard [RFC6749].
>
> On page 72, Figure 3.1 there is a diagram flow that is rather different
> from the diagram flow that is present in RFC 6749 Figure 1.
> In Figure 3.1,  an entity combines the roles of the AS and the RS whereas
> in Figure 1 : Abstract Protocol Flow (Page 7), these two
> roles are under the control of two separate entities. This means that the
> formal Model of OAuth is NOT closely following the OAuth 2.0
> standard [RFC 6749].
>
> On page 29, the text continues with:
>
> Our model includes clients and AS/RS that (simultaneously) support all
> four modes of operation available in OAuth and
> *can be dynamically corrupted by the adversary*.
>
> With the ABC attack, clients are not *dynamically corrupted by an
> adversary*, since Alice and Bob voluntarily cooperate to achieve
> a common goal: to cheat a RS. As a consequence, the dissertation does not
> consider collaborative clients or collusion between clients.
>
> The same problem appeared with the ABC4Trust EU project (Attribute-based
> Credentials for Trust) which has now ended.
> *U-Prove* from Microsoft and *Identity Mixer* from IBM were used as a
> demonstrating technology of the principles.
> However during the project, no one ever considered the case of the Alice
> and Bob collusion attack. So all experts involved
> in this project believed that these two technologies were secure, whereas
> they were not, even when smart cards were being used.
>
> You wrote :
>
> " A commonly accepted security property for OAuth would be:
>
>   An attacker should not be able to obtain access to or use a protected
> resource protected by an uncompromised AS
>   if that resource is only used by an honest user with an uncompromised
> client and user agent."
>
> This sentence has nothing to do with a "security property". This term is
> defined in ISO/IEC TS 19249:2017, 3.1:
>
> *security property*
> *property* of a system or application *that is crucial to achieve the
> security objectives defined for the system or application*
>
> On the contrary, it is *c**rucial to prevent collaborative users to cheat
> a RS using an uncompromised AS*.
>
> You also wrote:
>
> Being resistant to collusion attacks is not a commonly accepted/expected
> security property.
>
> Being resistant to collusion attacks is indeed a security property.
>
> Considering only honest users is an hypothesis that does not correspond to
> the real world. Currently, when reading the current document
> even through the lines, it is impossible to guess that the ABC attack may
> ever exist.
>
> Now, the question is : Is OAuth 2.0 able to meet such a property ? I read
> again my previous emails and the answer is ... *YES*.
>
> I considered two cases:
>
> a) When the JWT contains one or more attributes that uniquely allow to
> identify the collaborative user, then the other client
> will be in a position to impersonate the collaborative user. There is no
> advantage for Alice because she will simply be able to
> impersonate Bob and she will not take any advantage of the attributes from
> Bob for herself.
>
> b) When the JWT does not contain a sufficient number of attributes that
> would allow to identify the user,
> the collaborative user can transmit it to anybody else, without the risk
> to be detected by the RS.  E.g. it
> only contains the age of the user and a membership to a large group of
> people. This case can only be countered
> using secure elements with specific properties.
>
> When the token contains one or more attributes that uniquely allow to
> identify the collaborative user (e.g. a "sub" claim),
> then Alice can only impersonate the collaborative user and such a case can
> easily be obtained using TeamViewer.
>
>
>    - Unfortunately using the "sub" claim is not "privacy friendly", since
>    collaborative RSs will be able to link the accounts
>    of their respective users.  Nevertheless, this a good news for
>    Vittorio, since the "sub" claim is REQUIRED in the
>    "Profile for OAuth 2.0 Access Tokens". This means that, *when this
>    profile is being used, OAuth 2.0 is resistant *
> *to the ABC attack*.
>
>    - Using a different claim that would only contain an identifier that
>    is unique to the RS (such as a pseudo) would be
>    more appropriate (as FIDO does), but I am not aware of a claim that
>    has been defined which would have such a semantics.
>
> The "*Updated *OAuth 2.0 Attacker Model" is supposed to have been
> "updated to account for the potentially
> *dynamic relationships involving multiple parties*. As explained above,
> this is not the case for clients since multiple clients have not been
> considered.
> This is also not the case for RSs since multiple RSs have not been
> considered.
>
> Anyway, in order to correctly explain the cases, there needs to be a
> discussion in this document both about the ABC attack
> *and* the content of the token. There should also be a discussion about
> multiple RSs where an RS attempts to forward a received token
> to another RS. Even if the countermeasure is obvious, it should be
> mentioned in this document.
>
> To summarize my findings about the dissertation, it is not able to address
> these cases since it only consider attackers that can either be :
>
>    - "Web attackers (who can listen to and send messages from their own
>    addresses only)" or
>    - "Network attackers (who may listen to and spoof all addresses and
>    therefore are the most powerful attackers)".
>
> Denis
>
> Hi Denis,
>
> Am 07.05.20 um 14:46 schrieb Denis:
>
> (...)
>
> A new definition for the term client should be adopted for this document.
> However, you are right, the two wordings shall remain.
>
> I cannot follow any of this, sorry.
>
>
> 3) The "*Updated *OAuth 2.0 Attacker Model" is supposed to have been
> "updated to account for the potentially *dynamic relationships involving
> multiple parties*".
> However, it still misses to address the case of *dynamic relationships
> between clients*, which include scenarios of *collaborative clients*.
>
> That is not correct. Web attackers (A1) can participate in the protocol as
> one or more users (resource owners) or clients. Of course, these can
> collaborate between each other.
>
> Section 3 states:
>
>    *OAuth MUST ensure that* the authorization of the resource owner (RO)
> (with a user agent) at the authorization server (AS) and
>    the subsequent usage of the access token at the resource server (RS) *is
> protected at least against the following attackers*:
>
>   *  (A1) *Web Attackers *(...)
>
> If a collaboration / collusion between clients were covered under this
> case, then it would mean that *OAUTH MUST provide a protection for it*,
> whereas this is technically impossible.
>
> You are confusing the attacker model with the security goals (aka security
> properties).
>
> A commonly accepted security property for OAuth would be:
>
> "An attacker should not be able to obtain access to or use a protected
> resource protected by an uncompromised AS if that resource is only used by
> an honest user with an uncompromised client and user agent."
>
> (roughly equivalent to the one in
> https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf
> )
>
> Being resistant to collusion attacks is not a commonly accepted/expected
> security property.
>
> So: Yes, attackers are free to collude, and that is part of the model. No,
> that is not a problem, as they are not breaking anything anyone would
> expect.
>
> -Daniel
>
>
> Since AOuth is unable to protect against a collusion attack between
> clients, the collusion attack cannot belong to this section, in particular
> under (A1).
>
> Section 3 is confusing the threat model with the resistance of OAuth to
> these threats.
>
> At this time, an RFC reader may not catch the fact that a collusion attack
> between clients may ever exist and thus may not
> grasp the fact that this kind of attack cannot be countered by OAuth, even
> when following the Best Practices.
>
> The "Updated OAuth 2.0 Attacker Model" does not take into "account for
> the potentially *dynamic relationships involving multiple parties*".
> as it is advertised, in particular the case of *dynamic relationships
> between clients* which include the case of *collaborative clients*.
>
> The text currently does not  incorporate words like "collusion",
> "colluding", whereas it should. The text should clearly indicate that
> a protection against a collusion between clients is currently not possible
> using OAuth.
>
> Such a collaboration between clients is possible and should be considered
> in the "updated model".
>
> This is considered in the model.
>
> See my comments above. While promised by the text, the case of
> collaborative clients is not considered in the model.
>
> which are human beings, it cannot be assumed that all the human beings in
> the world will necessary be honest. Whether or not Auth 2.0 is able or not
> to counter such an attack is another issue.
>
> This as well.
>
> As said above, the model should only express the threats (or the possible
> attacks) and another section should indicate which threats cannot
> countered.
>
> In another section, it should be mentioned that OAuth 2.0 is unable to
> counter such an attack.
>
> The problem is not that this type of collusion attack is not possible
> under the model. The problem is it is not commonly expected that OAuth
> protects against this type of attack.
>
> RFC readers who have not followed or participated to this thread will not
> necessarily know that OAuth does not protect against this type of attack.
>
> The purpose of this document is to inform the reader about *all* known
> types of attacks, whether they can be defeated or not by OAuth 2.0.
>
> Denis
>
> -Daniel
>
> Stating that such an attack is "out of the scope" of OAuth 2.0 would not
> be an appropriate statement.
>
> It should not be forgotten, that the purpose of this document is to inform
> the reader about *all* the relevant security issues.
>
> Denis
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>         Title           : OAuth 2.0 Security Best Current Practice
>         Authors         : Torsten Lodderstedt
>                           John Bradley
>                           Andrey Labunets
>                           Daniel Fett
> 	Filename        : draft-ietf-oauth-security-topics-15.txt
> 	Pages           : 46
> 	Date            : 2020-04-05
>
> Abstract:
>    This document describes best current security practice for OAuth 2.0.
>    It updates and extends the OAuth 2.0 Security Threat Model to
>    incorporate practical experiences gathered since OAuth 2.0 was
>    published and covers new threats relevant due to the broader
>    application of OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>
> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000195d6b05a5812c65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

In section 4.=
1.3. Countermeasures related=C2=A0to 4.1.=C2=A0 Insufficient Red=
irect URI Validation it states

   The complexity of implementing and =
managing pattern matching
   correctly obviously causes security issues.  This document therefore
   advises to simplify the required logic and configuration by using
   exact redirect URI matching only.  This means the authorization
   server MUST compare the two URIs using simple string comparison as
   defined in [RFC3986], Section=C2=A06.2.1.

Does this mean that the authorisation server MU=
ST NOT use pattern matching at all and MUST do simple string comparison for=
 redirect URI?
If that is the case can we change the wording a bit in th=
is section as having "...therefore advises to simplify the requ=
ired logic..." gives the impression that the AS has the choice to deci=
de whether or not to use pattern matching. And then when we have "...a=
uthorization
   server MUST compare the two URIs using simple string..." giv=
e the impression that the AS should absolutely not(MUST NOT) use pattern ma=
tching.

Best Regards,
Janak Amarasen=
a

On Fri, May 8, 2020 at 2:53 PM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Daniel,

    


    

    
Thank you for pointing to your
      dissertation which has the following title : An Expressive Formal
      Model of the Web Infrastructure.

      

    

    
Since it is 240 pages long (or thick),
      I have not read everything but some sentences brought my
      attention.

    


    

    
I have experienced formal models in the
      past and everything depends upon the hypothesis that are made
      upfront.

    


    

    
On page 28:

    

    

      
1.1.1. The Web Infrastructure Model

      


      

      
(...) 

      

      
Altogether, the model is the most
          comprehensive and detailed model for the web infrastructure to
          date [i.e. in year 2018].

      
(...)

    

    
On page 40, there is the following
      sentence:

    

      
A browser is thought to be used by
          one honest user, who is modeled as part of the browser.

    

    


      With such an hypothesis, it is impossible to consider a collusion
      attack between clients, hence the Model omits to consider such a
      case.

    
When using a formal approach, it is
      generally not possible to make sure that all attacks have been
      considered, but when considering 

      specific attacks, it is possible to demonstrate that they can be
      countered (or not).

    


    

    Many models are considering "adversaries". This originates fr=
om the
    "Alice, Bob and Carol model" where both Alice and Bob 

    
were honest and where Carol was the
      attacker. In the case of the "Alice and Bob Collusion attack&quo=
t;,
      Alice and Bob are good friends. 

      The target of the attack is a RS. The RS is not an adversary : it
      does nothing bad. Alice and Bob are adversaries towards Carol (the
      RS).

    
This can bee seen as the revenge of
      "Alice and Bob" against Carol.=C2=A0 :-)

    

    


    

    
On page 29, the text states:

    

      
Model of OAuth 2.0

        

      

      
Using our generic web model, we build
        a formal model of OAuth, closely following the OAuth 2.0
        standard [RFC6749].

    

    
On page 72, Figure 3.1 there is a
      diagram flow that is rather different from the diagram flow that
      is present in RFC 6749 Figure 1.

    
In Figure 3.1,=C2=A0 an entity combines the
      roles of the AS and the RS whereas in Figure 1 : Abstract Protocol
      Flow (Page 7), these two 

      roles are under the control of two separate entities. This means
      that the formal Model of OAuth is NOT closely following the OAuth
      2.0 

      standard [RFC 6749].

      

    

    
On page 29, the text continues with:

    

      
Our model includes clients and AS/RS
        that (simultaneously) support all four modes of operation
        available in OAuth and 

        can be dynamically corrupted by the adversary.

      

    

    
With the ABC attack, clients are not dynamically
        corrupted by an adversary, since Alice and Bob voluntarily
      cooperate to achieve 

      a common goal: to cheat a RS. As a consequence, the dissertation
      does not consider collaborative clients or collusion between
      clients. 

    


    

    

      
The same problem appeared with the
        ABC4Trust EU project (Attribute-based Credentials for Trust)
        which has now ended.

      
U-Prove from Microsoft and Identity
          Mixer from IBM were used as a demonstrating technology of
        the principles.

        However during the project, no one ever considered the case of
        the Alice and Bob collusion attack. So all experts involved 

        in this project believed that these two technologies were
        secure, whereas they were not, even when smart cards were being
        used.

    

    


    

    
 You wrote :

    

      

        
" A commonly accepted security property for OAuth would be:=
 

          

          =C2=A0 An attacker should not be able to obtain access to or use =
a
          protected resource protected by an uncompromised AS 

          =C2=A0 if that resource is only used by an honest user with an
          uncompromised client and user agent."

      

    

    
This sentence has nothing to do with a "security property"=
. This
      term is defined in ISO/IEC TS 19249:2017, 3.1:

    

      
security property

        property of a system or application that is crucial
          to achieve the security objectives defined for the system or
          application

    

    
On the contrary, it is crucial to prevent
        collaborative users to cheat a RS using an uncompromised AS.
      

    

    
You also wrote:
    

    

      
Being resistant to collusion attacks is not a commonly
        accepted/expected security property.

    

    
Being resistant to collusion attacks is indeed a security
      property. 

    

    
Considering only honest users is an hypothesis that does not
      correspond to the real world. Currently, when reading the current
      document

      even through the lines, it is impossible to guess that the ABC
      attack may ever exist.
    

    
Now, the question is : Is OAuth 2.0 able to meet such a property
      ? I read again my previous emails and the answer is ... YES.
      

    

    
I considered two cases: 

    

    

      
a) When the JWT contains one or more attributes that uniquely
        allow to identify the collaborative user, then the other client
        

        will be in a position to impersonate the collaborative user.
        There is no advantage for Alice because she will simply be able
        to 

        impersonate Bob and she will not take any advantage of the
        attributes from Bob for herself.

      
b) When the JWT does not contain a sufficient number of
        attributes that would allow to identify the user,

        the collaborative user can transmit it to anybody else, without
        the risk to be detected by the RS.=C2=A0 E.g. it 

        only contains the age of the user and a membership to a large
        group of people. This case can only be countered 

        using secure elements with specific properties.

    

    
When the token contains one or more attributes that uniquely
      allow to identify the collaborative user (e.g. a "sub" clai=
m), 

      then Alice can only impersonate the collaborative user and such a
      case can easily be obtained using TeamViewer.

    

    

      
    
        
  • Unfortunately using the "sub" claim is not "priv=
acy
          friendly", since collaborative RSs will be able to link the
          accounts 
    
          of their respective users.=C2=A0 Nevertheless, this a good news f=
or
          Vittorio, since the "sub" claim is REQUIRED in the 
    
          "Profile for OAuth 2.0 Access Tokens". This means that,=
 when
            this profile is being used, OAuth 2.0 is resistant to
            
    
            the ABC attack    . 
    
          
    
        
    • 
        
  • Using a different claim that would only contain an
          identifier that is unique to the RS (such as a pseudo) would
          be
    
          more appropriate (as FIDO does), but I am not aware of a claim
          that has been defined which would have such a semantics.
    • 
      

    

    
The "Upda=
ted OAuth 2.0 Attacker Model" is
        supposed to have been "updated to account for the potentially =
dynamic
          relationships 

          involving multiple parties. As explained above, this is
        not the case for clients since multiple clients have not been
        considered. 

        This is also not the case for RSs since multiple RSs have not
        been considered.

    
Anyway, in order to correctly explain the cases, there needs to
      be a discussion in this document both about the ABC attack 

      and the content of the token. There should also be a
      discussion about multiple RSs where an RS attempts to forward a
      received token 

      to another RS. Even if the countermeasure is obvious, it should be
      mentioned in this document.

    
To summarize my findings about the dissertation, it is not able
      to address these cases since it only consider attackers that can
      either be :

    
    
      
  • "Web attackers (who can listen to and send messages from the=
ir
        own addresses only)" or
    • 
      
  • "Network attackers (who may listen to and spoof all addresse=
s
        and therefore are the most powerful attackers)".
    
      
    • 
    

    
Denis

    


    

    

     =20
      
Hi Denis,

      

      


      

      
Am 07.05.20 um 14:46 schrieb Denis:

      

      

       =20
        (...)

        
A new definition for the term client should be adopted for
          this document.=C2=A0 However, you are right, the two wordings sha=
ll
          remain.

        

      

      
I cannot follow any of this, sorry.

      

        

          

            


              
3) The "Updated OAuth 2.0
                  Attacker Model" is supposed to have been "updat=
ed to
                  account for the potentially dynamic relationships
                    involving multiple parties". 

                  However, it still misses to address the case of dynami=
c
                    relationships between clients, which include
                  scenarios of collaborative clients.

                

            

          

          
That is not correct. Web attackers (A1) can participate in
            the protocol as one or more users (resource owners) or
            clients. Of course, these can collaborate between each
            other.

        

        
Section 3 states:

        
=C2=A0=C2=A0 OAuth MUST ensure that the authorization of =
the
          resource owner (RO)=C2=A0 (with a user agent) at the authorizatio=
n
          server (AS) and 

          =C2=A0=C2=A0 the subsequent usage of the access token at the reso=
urce
          server (RS) is protected at least against the
            following attackers:

        
=C2=A0 *=C2=A0 (A1) Web Attackers (...)

        
If a collaboration / collusion between clients were covered
          under this case, then it would mean that OAUTH MUST
            provide a protection for it, 

          whereas this is technically impossible.

        

      

      
You are confusing the attacker model with the security goals
        (aka security properties).

      
A commonly accepted security property for OAuth would be:

      
"An attacker should not be able to obtain access to or use a
        protected resource protected by an uncompromised AS if that
        resource is only used by an honest user with an uncompromised
        client and user agent."

      
(roughly equivalent to the one in
        https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An=
%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)
      

      
Being resistant to collusion attacks is not a commonly
        accepted/expected security property.

      
So: Yes, attackers are free to collude, and that is part of the
        model. No, that is not a problem, as they are not breaking
        anything anyone would expect.

      

      
-Daniel

      

      


      

      

        
 

        
Since AOuth is unable to protect against a collusion attack
          between clients, the collusion attack cannot belong to this
          section, in particular under (A1).

        
Section 3 is confusing the threat model with the resistance
          of OAuth to these threats.

        
At this time, an RFC reader may not catch the fact that a
          collusion attack between clients may ever exist and thus may
          not 

          grasp the fact that this kind of attack cannot be countered by
          OAuth, even when following the Best Practices.

        
The "Upd=
ated OAuth 2.0 Attacker Model" does
            not take into "account for the potentially dynamic
              relationships involving multiple parties". 

            as it is advertised, in particular the case of dynamic
              relationships between clients which include the case
            of collaborative clients.

        
The text currently does not=C2=A0 incorporate words like
          "collusion", "colluding", whereas it should. =
The text should
          clearly indicate that 

          a protection against a collusion between clients is currently
          not possible using OAuth.

        

          

            

              
 Such a collaboration between clients is
                  possible and should be considered in the "updated
                  model". 

                

            

          

          This is considered in the model.

        

        
See my comments above. While promised by the text, the case
          of collaborative clients is not considered in the model.

        

          

            

              
 which are human beings, it cannot be
                  assumed that all the human beings in the world will
                  necessary be honest. Whether or not Auth 2.0 is able
                  or not 

                  to counter such an attack is another issue.

                

            

          

          This as well. 

        
As said above, the model should only express the threats (or
          the possible attacks) and another section should indicate
          which threats cannot countered.=C2=A0 

        

        

          

            

              
 

              
In another section, it should be
                  mentioned that OAuth 2.0 is unable to counter such an
                  attack.

                

            

          

          
The problem is not that this type of collusion attack is
            not possible under the model. The problem is it is not
            commonly expected that OAuth protects against this type of
            attack.

        

        
RFC readers who have not followed or participated to this
          thread will not necessarily know that OAuth does not protect
          against this type of attack.

        
The purpose o=
f this document is to inform the
            reader about all known types of attacks, whether
            they can be defeated or not by OAuth 2.0.

        
Denis

        

          
-Daniel

          

          

            

              
 Stating that such an attack is "out of
                  the scope" of OAut=
h 2.0 would not be an
                  appropriate statement.

                

              
It should not be forgotten, that the
                  purpose of this document is to inform the reader about
                  all the relevant security issues.

                  

                  Denis

            

            

              
A New Internet-Draft is available from the on-line Inter=
net-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-15.txt
	Pages           : 46
	Date            : 2020-04-05

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-to=
pics-15
https://datatracker.ietf.org/doc/html/draft-ie=
tf-oauth-security-topics-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-o=
auth-security-topics-15


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

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


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


            

            


            

            

            

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


          

          


          

          

          

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


        

        


        

        

        

        
_______________________________________________
OAuth mailing list
OAuth@ietf.org
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




--000000000000195d6b05a5812c65--


From nobody Wed May 13 02:03:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4347C3A0FDD for ; Wed, 13 May 2020 02:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=dsWoGJSd; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=dsWoGJSd
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snP9R93E0teX for ; Wed, 13 May 2020 02:03:50 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2071.outbound.protection.outlook.com [40.107.20.71]) (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 2CB473A0FE3 for ; Wed, 13 May 2020 02:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/VOjARgZ3s1kpgrGZZQuWbMGhpeXOvYumVpD2rOyR4=; b=dsWoGJSdujvYneZtY3YOZnLzmLsohXF2PuM+3wl9RHL0jGoA6+pJDhrM78rhMyBObPMb1OB5gbiSUWsa2B7NFlsCGxRftGDqbZ7RyswQKKWKGzZOYFxVgbi5NbIuli5vZlr6PAm6lawWuKi8Bo+CwRxx68Cz4swHuWsy42s4vxg=
Received: from AM5PR1001CA0043.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:206:15::20) by HE1PR0801MB1818.eurprd08.prod.outlook.com (2603:10a6:3:7b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.34; Wed, 13 May 2020 09:03:45 +0000
Received: from AM5EUR03FT064.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:15:cafe::52) by AM5PR1001CA0043.outlook.office365.com (2603:10a6:206:15::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20 via Frontend Transport; Wed, 13 May 2020 09:03:45 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT064.mail.protection.outlook.com (10.152.17.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19 via Frontend Transport; Wed, 13 May 2020 09:03:45 +0000
Received: ("Tessian outbound 4cdf5642225a:v54"); Wed, 13 May 2020 09:03:45 +0000
X-CR-MTA-TID: 64aa7808
Received: from 412e6d11eee5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1EDBC744-8F3F-4BD0-B08B-8C60AFEB0443.1;  Wed, 13 May 2020 09:03:39 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 412e6d11eee5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 13 May 2020 09:03:39 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GfzWZfTXi2f9GkaT1OsZr37Ijw4i8e/u6nuomFPl05uhhdK5wwpQ6zcrVCwfzGpPDdpXt34z5MnoOCAV99JEubt6Ktn0hnjqiRYhEM+NzQ/oARBEIIJMfje6kxWpQAgA/nR+7ZdrD5RbxNHLCjzrLOtioRCKi7h+u3xwDgX+XEq9pYfMg5c7/D4U33h2XOTE5VwKP16bO02juzpwbjbdwWTVRhf4DbXYW8r3u0t9uJ4CsFtJDYkwEFkzWcZ5eGx+ld3HGh3KH2ZaSoDXHA22u4+pWOHn5+Z5a6ZyeSReSQzOttbK3dieeZChaQBewr0zhUXU3BlsXfgNupa+lO87Xg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/VOjARgZ3s1kpgrGZZQuWbMGhpeXOvYumVpD2rOyR4=; b=lR/KXeA/gqarrACu5Bt9PJFMC6yCO1knSB5Xf4tOhyub+vA/QFU6N6ESpbt1dOUtib5KGu+4MjpAzLdsrP1uez0hQFAzfU9wil+oOImsJF+k5k3L4acWrdsZ+88B9ITxKNLkh8DW2kpIi00Uys1XgflSvMtig1XldEwNZBHuQ0JeEyj2R7/HyXDIzV627pke8cxmAnG0scy9RSyyD2UhlT+Uwl/TwpiOAoSA1su3Brv2NrmBmbcrqNi5BeCezJMMQLeSv84tNR5eksXFGSmH8eH+Poi2vjQB0zi7i9q8FZ7al2YWHvs5kSHr6jZLWc0+NXTSeVJ5qY9tq/9sQKt9ug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/VOjARgZ3s1kpgrGZZQuWbMGhpeXOvYumVpD2rOyR4=; b=dsWoGJSdujvYneZtY3YOZnLzmLsohXF2PuM+3wl9RHL0jGoA6+pJDhrM78rhMyBObPMb1OB5gbiSUWsa2B7NFlsCGxRftGDqbZ7RyswQKKWKGzZOYFxVgbi5NbIuli5vZlr6PAm6lawWuKi8Bo+CwRxx68Cz4swHuWsy42s4vxg=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3313.eurprd08.prod.outlook.com (2603:10a6:208:5b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.30; Wed, 13 May 2020 09:03:38 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee%6]) with mapi id 15.20.2979.033; Wed, 13 May 2020 09:03:38 +0000
From: Hannes Tschofenig 
To: oauth 
Thread-Topic: Virtual Interim meeting next Monday, May 18th -- DPOP Discussion
Thread-Index: AdYpBU5PUkG53s4uRiiswbgYR2lRwA==
Date: Wed, 13 May 2020 09:03:38 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ts-tracking-id: f5452fdd-0ddb-40ef-b225-5499924d3df4.0
x-checkrecipientchecked: true
Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com;
x-originating-ip: [80.92.122.242]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 928b1ac9-23ab-452a-f69a-08d7f71c8a82
x-ms-traffictypediagnostic: AM0PR08MB3313:|HE1PR0801MB1818:
X-Microsoft-Antispam-PRVS: 
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:4303;OLM:6790;
x-forefront-prvs: 0402872DA1
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: uAcA9jOymOBu/mC1qDvQmeeXJzlLG+pWnKiIWjCUPenh/rLmWWgofDS0VBIcHd+EpdRrMmqXoH8B0p4pjGxCXl2JNunhb5V5eP8mUnwRrFG00QK/Zpfj0rVH/TBpz166Ol46GxasPDQmlB+9aynhcvP8Njd/lAkKs4kyU7wyntQlmE4d4SL4LO846cOZLV5LQz3QNMSyihjOSMJqbDoJlcPkjbLQ4njZOW3CUPbjGf/whlx4xHY35IIwwQHMpIhBAVMLwaT1zY4nYwN79hK7atp9EHdVV5By3ZCVLDX7BCc6l4tkt9JE7vgZc+fGDuw3LNDxyV/5fCIVfsXjA27Fk1bn5vT4bSntcA1MUKJOuRaoweR7ii9D5c192Yucyf41Yt/Uht99PYS/QLF5BWFQsoS5y288rkt5NybCmHEFqxJ/jz5m14hLmA7qqxdNeSu4bm2HsQNwFwpaFK8Qt+QnUihr3QS+In4k9fNqHnDZXS61Iy4xdyPuWQqeBCCdhPgShUMlrzE8ekDbp8HunZHDtQ==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(376002)(346002)(396003)(39850400004)(33430700001)(33656002)(7696005)(8936002)(99936003)(66476007)(66446008)(33440700001)(66556008)(8676002)(5660300002)(9686003)(64756008)(66616009)(55016002)(76116006)(4744005)(66946007)(71200400001)(86362001)(2906002)(6506007)(478600001)(316002)(186003)(6916009)(52536014)(26005); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: XnjEYuT2uUNvtwi8uAJwnj7EnvXfBu5TAFjZApHe+Imm3E5NuHoXTV4lFjY8xo62pAAX7WPLwqYNKhlHlGkf/pq9ugTSI860wqx5Ur9oqUfZkTA5VpdENBW7sXPn1F0B8uADsqf3o/s6mnXgrjq9/LV5uSE9+gkNrKe4m0nou/fYwR4ZdBmSu/VJeu6Q9R4MyGv3kYRZ3O4mtatZsjwkUTQvexkV4yq1xy+UC5N5n0QD/WsR+Fq/xNXhwDgDsFqla+5A+5IRTWrdmRXhnHRyyxp9uoUW/+CHivTdirlD0jyHOJDoSeO7FQDzGD2bWG+hb7Il7bF+KOls7s6y1sstgp4M/tjr8aBY4VN+4e4SUpM6Ah9jWYZgats7GKZVUMaI1yLK7OEfudFTafv5CT2NfnFeNti1pNRwoCb7kH+rw9Eb6btOuEwzv0Py6R0zHAwDP3+cABALsvx1hqh8xwlw2Y8GSP05BHwnMIJFKAU6QKCC6v4GKk2lM8iXAc80PdjC
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_004_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3313
Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT064.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;  IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;  PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(136003)(39860400002)(46966005)(33430700001)(70206006)(2906002)(52536014)(235185007)(336012)(7696005)(36906005)(33440700001)(8936002)(186003)(9686003)(6506007)(26005)(47076004)(70586007)(8676002)(66616009)(5660300002)(55016002)(316002)(356005)(33656002)(6916009)(82310400002)(82740400003)(99936003)(86362001)(81166007)(478600001); DIR:OUT; SFP:1101; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: 449cc8b1-0553-4b6a-418d-08d7f71c86bc
X-Forefront-PRVS: 0402872DA1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 1RSfdK3LyexDUV/3v0XZbVLB2XN8AmZmcJS3P0GouVDcOtpbd2a8f6b4JLzIDd0ZRa7z8v2KQo6ERHNwn/VEE4XGAE1Y4hrkmqvx7hJydhaQazOmuW3D8BkCnThFGpmjj2NJRl3ftA55nvaMkFWBVYmm9K87Ev4f2BynyfsgxENz7DLIc1LqdJj1VUrP72rJWPmkbZHOev/g048ye2+yy48IpOQutbalUO8y7PBLukyHmAMLSHo+T9rWjqWiejfKCJeK9uFEvaueP7GfUHNWrN9eDdAaOAEnSyUN0zAo6VKzbkZz0pkc5tgncXZS9AfIlD4Gc6Teey+MkTnBl0ByLiS5lC/QrLK2+43lNhR2mnZf3fdGdfYgG6SQx/c6qzux9ZVkQA7lZ/Lb9bRDy9VxkKnHbvkEHnAK9ErrrK645cARfOfo0DULTbRK8h6NLKvh2HIGMSxdYBqv+kjAcDNnW00Xg6OxxByhAcwlwElXDGzMZJS8ExGvEeEhVKCNg8xwMKWKuHz6BplD2vYMNiB0bLSvdfNj4mzIKkwm8x3qTQygsMXRRA1a42jaHnZuTB+EfT3gzHOiFgbSgsV1eW76qg==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 09:03:45.0398 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 928b1ac9-23ab-452a-f69a-08d7f71c8a82
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];  Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1818
Archived-At: 
Subject: [OAUTH-WG] Virtual Interim meeting next Monday, May 18th -- DPOP Discussion
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 09:03:52 -0000

--_004_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_
Content-Type: multipart/alternative;
 boundary="_000_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_"

--_000_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

As discussed at the last virtual interim meeting call we will add another s=
lot next Monday to talk about DPOP. This is a continuation of the DPOP disc=
ussion we had during one of our virtual interim meeting slots.

Please find the meeting invite in the calendar.

Ciao
Hannes & Rifaat

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

--_000_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all, 


 


As discussed at the last virtual interim meeting cal=
l we will add another slot next Monday to talk about DPOP. This is a contin=
uation of the DPOP discussion we had during one of our virtual interim meet=
ing slots.



 


Please find the meeting invite in the calendar. 


 


Ciao


Hannes & Rifaat


 



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



--_000_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_--

--_004_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_
Content-Type: text/calendar; name="OAuth_ConfCall_18May2020.ics"
Content-Description: OAuth_ConfCall_18May2020.ics
Content-Disposition: attachment; filename="OAuth_ConfCall_18May2020.ics";
 size=6476; creation-date="Wed, 13 May 2020 09:02:28 GMT";
 modification-date="Wed, 13 May 2020 09:02:25 GMT"
Content-Transfer-Encoding: base64

QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg
MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP
TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTgxMDAxVDAzMDAw
MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G
RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6
U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE4MDMwMVQwMjAwMDAKUlJVTEU6RlJF
UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx
MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM
SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApDTEFTUzpQVUJMSUMKREVTQ1JJUFRJT046
XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw
P01USUQ9bTcyMTAwMDQxMjhhYTFkYmE4Nzg4NGEyYzBlZTgwNmEwXG5NZWV0aW5nIG51bWJlciAo
YWNjZXNzIGNvZGUpOiA2MTQgNTIwIDAzOVxuXG5NZWV0aW5nIHBhc3N3b3JkOiBCV3NBRjlyVFxu
XG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAo
VVMvQ2FuYWRhKSBcblRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMg
bm90IHN1cHBvcnRlZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjYxNDUyMDAzOSUyMyUy
MyowMSpcblxuXG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwg
c2lwOjYxNDUyMDAzOUBpZXRmLndlYmV4LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4y
LjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9z
b2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjE0NTIw
MDM5LmlldGZAbHluYy53ZWJleC5jb21cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENv
bnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxu
SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxs
b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0
byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl
ci4gWW91IHNob3VsZCBpbmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9yIHRvIHJlY29y
ZGluZyBpZiB5b3UgaW50ZW5kIHRvIHJlY29yZCB0aGUgbWVldGluZy5cbgpYLUFMVC1ERVNDO0ZN
VFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+KiB7ICAgIHBhZGRpbmc6IDA7
ICAgIG1hcmdpbjogMDt9dGFibGUgewlib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9
MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9dHIgewlsaW5lLWhlaWdodDogMThw
eDt9YSwgdGQgewlmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMz
MzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAw
O30udGl0bGUgewlmb250LXNpemU6IDI4cHg7fS5pbWFnZSB7CXdpZHRoOiBhdXRvOwltYXgtd2lk
dGg6IGF1dG87fS5mb290ZXIgewl3aWR0aDogNjA0cHg7fS5tYWluIHt9QG1lZGlhIHNjcmVlbiBh
bmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7CS50aXRsZSB7CQlmb250LXNpemU6IDIycHgg
IWltcG9ydGFudDsJfQkuaW1hZ2UgewkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0
aDogMTAwJSAhaW1wb3J0YW50Owl9CS5mb290ZXIgewkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJ
CW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudAl9CS5tYWluIHsJCXdpZHRoOiAxMDAlICFpbXBv
cnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnQJfX08L3N0eWxlPjx0YWJsZSBiZ2Nv
bG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdp
ZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZu
YnNwOzwvdGQ+PC90cj4JPHRyPgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAy
MHB4OyBtYXJnaW46IDAiPgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJv
cmRlcjogMHB4OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0
OiA1MHB4OyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj4JCQkJPHRyPgkJCQkJPHRkIGFsaWdu
PSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwvdGFi
bGU+LS0+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iNCIgQ09M
T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgV2ViZXgg
bWVldGluZyBoZXJlLjwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJCTx0ciBzdHlsZT0ibGlu
ZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+
CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD
RT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDYxNCA1MjAgMDM5PC9GT05U
PgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRk
PgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PC9GT05U
PgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJ
WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZP
TlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+
QldzQUY5clQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+ICAgICAgICA8dGFibGU+ICAgICAgICAJ
PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu
YnNwOzwvdGQ+PC90cj4JCQk8dHI+CQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7
ICI+CQkJCQk8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAi
IHN0eWxlPSJ3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6
IzQzQTk0MjsgYm9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1p
bi13aWR0aDoxNjBweCFpbXBvcnRhbnQ7Ij4JCQkJCQk8dHI+CQkJCQkJCTx0ZCBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi
ZXguY29tL2lldGYvai5waHA/TVRJRD1tNzIxMDAwNDEyOGFhMWRiYTg3ODg0YTJjMGVlODA2YTAi
IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v
bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD4JCQkJCQk8L3RyPgkJCQkJPC90YWJsZT4JCQkJPC90
ZD4JCQk8L3RyPgkJPC90YWJsZT4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiIHN0eWxl
PSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwi
PiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2
IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9
IjMiIENPTE9SPSIjOTk5OTk5IiBGQUNFPSJhcmlhbCI+VGFwIHRvIGNhbGwgaW4gZnJvbSBhIG1v
YmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5KTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9
IjIiIENPTE9SPSIjMzMzMzMzIiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3
OS0zMjA4LCwqMDEqNjE0NTIwMDM5JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwNDlGRDk7ICB0
ZXh0LWRlY29yYXRpb246bm9uZTsgJz4xLTY1MC00NzktMzIwODwvYT4mbmJzcDtDYWxsLWluIHRv
bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEJSPjx0YWJsZT48dHIgc3R5
bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90
ZD48L3RyPjwvdGFibGU+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMi
IENPTE9SPSIjOTk5OTk5IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9y
IGFwcGxpY2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzMzMzMzMyIgRkFD
RT0iYXJpYWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDo2MTQ1MjAwMzlAaWV0Zi53ZWJleC5j
b20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDQ5RkQ5IiBGQUNFPSJhcmlhbCI+NjE0NTIwMDM5
QGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIENPTE9SPSIjMzMzMzMz
IiBGQUNFPSJhcmlhbCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7
Y29sb3I6IzMzMzMzMztsaW5lLWhlaWdodDogMjRweDsiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4y
NDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+
PC9GT05UPiZuYnNwOyA8QlI+Jm5ic3A7IDxCUj48dGFibGU+PHRyPjx0ZCAgc3R5bGU9ImNvbG9y
OiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdo
dDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5j
IG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0i
bWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFs
OyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lw
OjYxNDUyMDAzOS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246
bm9uZTtjb2xvcjojMDQ5RkQ5Ij42MTQ1MjAwMzkuaWV0ZkBseW5jLndlYmV4LmNvbTwvYT48L3Rk
PjwvdHI+PC90YWJsZT4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQi
IGNsYXNzPSJtYWluIj4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0
ZD4mbmJzcDs8L3RkPjwvdHI+CQkJCTx0cj4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBj
b2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1o
ZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4
LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDov
L2hlbHAud2ViZXguY29tPC9hPgkJCQkJPC90ZD4JCQkJPC90cj4gICAgICAgICAgICAgICAgPHRy
IHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+CQkJPC90YWJsZT4JCTwv
dGQ+CTwvdHI+PC90YWJsZT4KQVRURU5ERUU7Q049IldlYiBBdXRob3JpemF0aW9uIFByb3RvY29s
IFdvcmtpbmcgR3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86b2F1
dGgtY2hhaXJzQGlldGYub3JnCkRUU1RBTVA6MjAyMDA1MThUMTYwMDAwWgpVSUQ6MjA0NWQzNTct
ZmU3OC00OTBhLWI5MDQtNTYwZGM3YWUzNjAyClBSSU9SSVRZOjUKUkVDVVJSRU5DRS1JRDtUWklE
PSJFdXJvcGUgVGltZSI6MjAyMDA1MThUMTgwMDAwCkRUU1RBUlQ7VFpJRD0iRXVyb3BlIFRpbWUi
OjIwMjAwNTE4VDE4MDAwMApEVEVORDtUWklEPSJFdXJvcGUgVGltZSI6MjAyMDA1MThUMTkwMDAw
ClNFUVVFTkNFOjE1ODkzNjAzMDQKU1VNTUFSWTpPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBIb3Vy
cwpUUkFOU1A6T1BBUVVFCk9SR0FOSVpFUjtDTj0iQ2lzY28gV2ViZXgiOk1BSUxUTzptZXNzZW5n
ZXJAd2ViZXguY29tCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpCRUdJTjpW
QUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpF
TkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo=

--_004_AM0PR08MB3716367CB5BAF35419EF058DFABF0AM0PR08MB3716eurp_--


From nobody Wed May 13 05:16:10 2020
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 8AD623A0442; Wed, 13 May 2020 05:15:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.130.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158937215806.9148.1182768951394743318@ietfa.amsl.com>
Date: Wed, 13 May 2020 05:15:58 -0700
Archived-At: 
Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 12:15:59 -0000

The Web Authorization Protocol (oauth) Working Group will hold
a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna (16:00 to 17:00 UTC).

Agenda:
DPOP
https://tools.ietf.org/html/draft-ietf-oauth-dpop-00

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b

https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/


From nobody Wed May 13 07:07:08 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ECD3A0A05 for ; Wed, 13 May 2020 07:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaurVBm1W_hW for ; Wed, 13 May 2020 07:07:05 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D58B3A0A04 for ; Wed, 13 May 2020 07:07:05 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id v12so21015903wrp.12 for ; Wed, 13 May 2020 07:07:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=s6pKQF/+dJBtXBqrmckNP+wR4b0NYY/sNqjvm7BxDKI=; b=I6NP8qm039L1T5oASTWMv1byk/9nt7Pr7cXhzGxfhJZBxlCwNQXw3NCR3o+D5qD4xd tQUVfmtofH+gGTmg0+UFHjyvpOiLKXgLpNxw9Mz+88erTck2OMI835+H0v9pD91JWcJK 0xYLFoMtBz+ZhZ6MhCnwzxL12l79/Vtv2x/yZZYJvE8XV/igPwTSb+XcZFS9nLPadVHN toWYuzR+gDUZQW94Me0DwjB5M8o9vMn4yx5RJleBiVQ2ZfUvu3xkuruKHNVGYC+jzVE7 A5K0z61hEC+Fn9QSIBVAOhYEfRNZnxuxZSusjpaX8o09K8aSWZXbfK4nCnOHA4HW3rkL vpWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=s6pKQF/+dJBtXBqrmckNP+wR4b0NYY/sNqjvm7BxDKI=; b=gEnEULpxzhNYkqVhaK8pnOsgBsHJFJumXUByQhL00SzSDo84QE7vJKxss/2W34Q4IH BPDWxCy2JBWBJGpD1agQ2qf9+Nf+dt9vWPTwjSYZN7YSYLvYn+muuAZo8d7UO68xvH4S UWCVbGNPcoLSiYYJzvUHsVeSxa+01sQ0BUp8XqXCDPcs2NLbgxOEsrfep+uowQp9VH8U FNAXetdYJnCyRFQhdZ/AImoWdDOmJZt7/RxwM0FzqzIM3p/Qj/eCYMvAPlFx+Sr07Rep FAmceGVvgBXfh+ne0QiaP+Yw2qfZkJiglue8LVr0BwVhPzsN/GkRfoWtlkOVzELexkT1 Q1lg==
X-Gm-Message-State: AGi0Puay7BVuTdnG/aVrZ699p6knwRHTWXkcK4I2Cje7PhtZJ7jEQQ+9 gTRW319C3KQfjdCJMcoAiksvaVEZSPJPgqXTnojdh6Odxp8=
X-Google-Smtp-Source: APiQypJK4PCQIZqx+YYvbxy46ecntrorRr+x5cbgPlMzAI+fvgsMPohQmHO3rxmW2sPjl9eOnpVLelxLC/heLVCCdKs=
X-Received: by 2002:adf:dc89:: with SMTP id r9mr29415911wrj.138.1589378823355;  Wed, 13 May 2020 07:07:03 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Wed, 13 May 2020 10:06:52 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002e029e05a58818d0"
Archived-At: 
Subject: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 14:07:07 -0000

--0000000000002e029e05a58818d0
Content-Type: text/plain; charset="UTF-8"

All,

Based on the 3rd WGLC, we believe that we have consensus to move this
document forward.
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

We will be working on the shepherd write-up and then submit the document to
the IESG soon.

Regards,
 Rifaat & Hannes

--0000000000002e029e05a58818d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

Based on the 3rd WGLC, we believe=
=C2=A0that we have consensus=C2=A0to move this document forward.


Regards,
=C2=A0Rifaat & Hannes

<=
/div>

--0000000000002e029e05a58818d0--


From nobody Wed May 13 08:17:11 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B12B3A0DAC for ; Wed, 13 May 2020 08:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaLdtYo1H4nq for ; Wed, 13 May 2020 08:17:08 -0700 (PDT)
Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF273A0D59 for ; Wed, 13 May 2020 08:15:29 -0700 (PDT)
Received: by mail-oo1-xc2c.google.com with SMTP id s139so26127oos.1 for ; Wed, 13 May 2020 08:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C7UmsEmINal0nZ3CJqnCFipv7Qib3JS8Rvi9sMXvOAs=; b=KZqhZO1PIbLSD6NDj6Dyr+FnQ/NC7DqQb9axDa5x+iO89apBwv8INEcjA76rYRuI9p SEYVwzfx8k89QoUy6r212rcGHg67/2JjXO89xM/yPzpzaANYxV1dXTVlyGj5MfnMfhWn 7/M6m2v5vXZKPXgGSmNSZHDvYoKnQCm/bEq3AMP6GHf8Qsx0NJ8rQfP8fhRxC854LiNh 67H6JDffNzB30/nrhefiedSBMs5QWF/1eHfzOnhG0iGYbD78J2NPSnIJnfiFEcUfXhNm 6pQq5SmQAHSo27buu5hcchq7B+GgtpK8UdcA4HlBziPeyhsm5hg5/pmV0A05R1PIczJE GGmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C7UmsEmINal0nZ3CJqnCFipv7Qib3JS8Rvi9sMXvOAs=; b=HwuuiKh59Bp7EGi6H/onh5SMqj7tUlGaVDZM/JkcuSzNobwlFEn3x+fmzqnGDXYg4z v2qis2SjPCybUc7qlTIDsfR2kvKse4gYkMkSJgLNTs1m+Z611r4Y7A12vDHfSambAk9g 8hEcJBsU4Vzy6rfgkGD898QsjSLMEPzRCg/FmpyoCRRHRaPAugf0BabGAZprCSxNKNry HdiqGh8/lCkTCsUjsXbA3SPnFT3eR31z6BjqouJMLD3jDo3qRQaW6AclFH2OnnraTlbf rz1PngVnEhjKm9ogRNRGxWu/YYpPaluw4hPKOmRzMbvXqohBEq/eUmsele0UlXQ3fY81 ZQ6A==
X-Gm-Message-State: AGi0PuZwOsA1RiU0t2IrpA4Cm9uiWYVZ3UNIjEYf9c+SK5YqZIExcAXu GYCq6pRHSeE63T07cjkA7nortxWMEIT59XKirN8lVg==
X-Google-Smtp-Source: APiQypJju+ZMpiA9zrht/d1OSmt7fsukBqZzJ+HlYX4gwAomPLEO5KZfO5Y/prObQ9seGuIwIhnR8jck5Vzkiew1v38=
X-Received: by 2002:a4a:e60d:: with SMTP id f13mr21983144oot.6.1589382927662;  Wed, 13 May 2020 08:15:27 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Steinar Noem 
Date: Wed, 13 May 2020 17:15:16 +0200
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000d0d8e905a5890ce2"
Archived-At: 
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 15:17:10 -0000

--000000000000d0d8e905a5890ce2
Content-Type: text/plain; charset="UTF-8"

Sorry for coming late in the game, but I really think that the "sub" claim
should be OPTIONAL instead of REQUIRED.

We are implementing OAuth 2.0 for the Norwegian health sector, where we
have several resources in production already.
I don't think the "sub" claim should have different meaning depending on
the flow - we would prefer to omit the sub claim in cases where the
resource owner isn't present.
This is not possible with the current language. We would like to be able to
choose if and how we use the "sub" - the "client_id" claim will always be
present.


Regards
Steinar

ons. 13. mai 2020 kl. 16:07 skrev Rifaat Shekh-Yusef <
rifaat.s.ietf@gmail.com>:

> All,
>
> Based on the 3rd WGLC, we believe that we have consensus to move this
> document forward.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>
> We will be working on the shepherd write-up and then submit the document
> to the IESG soon.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |

--000000000000d0d8e905a5890ce2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sorry for coming late in the game, but I really think that=
 the "sub" claim should be OPTIONAL instead of REQUIRED.
=C2=
=A0
We are implementing OAuth 2.0 for the Norwegian health sector, wher=
e we have several resources in production already.
I don't=
 think the "sub" claim should have different meaning depending on=
 the flow - we would prefer to omit the sub claim in cases where the resour=
ce owner isn't present.=C2=A0
This is not possible with the c=
urrent language. We would like to be able to choose if and how we use the &=
quot;sub" - the "client_id" claim will always=C2=A0be presen=
t.


Regards
Steinar=
=C2=A0=C2=A0

ons. 13. mai 2020 kl. 16:07 s=
krev Rifaat Shekh-Yusef <rifa=
at.s.ietf@gmail.com>:
All,

Based on the 3rd WGLC=
, we believe=C2=A0that we have consensus=C2=A0to move this document forward=
.

We=
 will be working on the shepherd write-up and then submit the document to t=
he IESG soon.

Regards,
=C2=A0Rifaat &=
; Hannes


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Vennlig hilsen=


Steinar Noem
Partner Udelt AS
Systemutvikler<=
/div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n=
o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.=
no=C2=A0|=C2=A0


--000000000000d0d8e905a5890ce2--


From nobody Wed May 13 10:00:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8F3A0B9C for ; Wed, 13 May 2020 10:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=HYWgU6dd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UI6ZPm+R
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEG22kkKFrCR for ; Wed, 13 May 2020 10:00:55 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3D53A0B85 for ; Wed, 13 May 2020 10:00:55 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 0AAE57E4 for ; Wed, 13 May 2020 13:00:54 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 13 May 2020 13:00:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= to:from:subject:message-id:date:mime-version:content-type; s= mesmtp; bh=7CerGyLih0s3DPbGcOfdpN1imm1fM0rFu6WcQw9Vn2M=; b=HYWgU 6ddFoyIJRLGt+P+1kYKTSFye7SYcvBE0mhMnqbNW+56iaJgi6UKad8M9/pc6GM6+ czkQNL/S9sY9t+9chzMXy8Cml1Nt1tuzEHKaOM1DxGFwhPrzl+0mPdMX4qw883/M 2dDSDF8aoFBzS2h8TF7UPt3yDwUUDjCZFjQzj4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=7CerGyLih0s3DPbGcOfdpN1imm1fM 0rFu6WcQw9Vn2M=; b=UI6ZPm+REPmjki0NUC5GiIdtQV/8ob6h/nKQq2nbeX5Bs L4/JyduwQv9Spv6V7heVkdcHNKaShiUBchsYhuLOPKfjWWlInqmEJqXu/mlvRfKI jT4YBJ5xCx9C6fnhyFpCFT8koi3K7urK8t7JetdkgrKKw4e5XMtivIDnyMLFFFoJ fYZxXAIOLFbMHRRin0MtnXctVbo7DawD0/lsxfqGdKLuTVAzylGRdtV8Z7fMCoy+ TQjWvOo7vurKFM0Ijy9jQP3geG2o9rfrvoL4tGGahiHH1prHmQWrwcd8qS1w5APc s0SIuZ7uuZMHJBdtG1KM1as2zO8UY2bF6dl8+jcng==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleeggddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffukffffgggtgesrgdtreertd efjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgtohhm qeenucggtffrrghtthgvrhhnpeeujeeiheevfeelfeejtdeghfelfeetieeijedtiedvud fgieeiuefhtdduleevhfenucfkphepjedtrddvgedriedvrddvtdejnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgvsegvvhgvrhhtphhoth drtghomh
X-ME-Proxy:    
Received: from [192.168.2.10] (toroon0954w-lp140-01-70-24-62-207.dsl.bell.ca [70.24.62.207]) by mail.messagingengine.com (Postfix) with ESMTPA id 081D4328005A for ; Wed, 13 May 2020 13:00:53 -0400 (EDT)
To: oauth 
From: Evert Pot 
Autocrypt: addr=me@evertpot.com; keydata= mQINBFzZpTYBEACt3GNTWOSosId2/7G1EHYWfva4gF4kgOL+/pew0+I2wTCyFeDXti+CRE1o 5LoCpTSGHDWZokSELeA2PwNX1ls7c2sZ7AVKWKhBLBhPEVo6YzlTli/B747ryGfMikiWYCRa e/yBJtyRuWuS8ArxCpEROzcUqCGZu7Rqs9RzUfYS7WZ85ne3DeRxPCCBIIlhlRu2lasjByPs IpSI0YSIpq4M5fLqbVdTjfqbTBGw82pDwQwlxO3J0T07dnvpEEheYspkMj/EGXqVTrLuoRw0 D7yObXgr0bcjuf+km8cdfZktclqCg1YajiseBBObw9IQpWiIE0oIxA7mAti1wus3JLxAfqCI tgzBtwEPeg6tcfzeDI9gnSl904g2+ozS0uFI61YHA/j70IxgIwyzp8QDsj0nS83aqaZV8k2U FNCnbriMftMCD/+iudRxfzq4VThkhIgfR9ZsaTvdWGIsAxCZyjaUHFMOBafjCMNjePCg74yA JSwdHhi6mzIuIfVGqsKXmO4Khzgm+c2qVq7cym93yp6kqNXOge9ZjQ2q96HHa64wXoYlNYZU 0fkvjkANj9V7ZC4PnavRMQHeFsW+vqU38pIFSppsqpeBggvV4U2WRHt2NyrE3ta9h1XTs9w3 SWSTujpJ/XGqPm7YYnNPrKXn5uvjEJ+OKt4+trpP1juUc3LJ8wARAQABtBtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT6JAk4EEwEIADgWIQTLR9Vo8uufCXNz2gLxiYR6BK2dDwUCXNml NgIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDxiYR6BK2dDyHmD/0bufc/UhM76R8S NSpYAds83HKt3XgIGPl8CEMaz35bkvlNypVUvd0iLy1MFgDDyqdXuM840HWL0grCC+g1LA8K eeHSYBDYm+ATlEu09FCN6+TdDbWBA19vmLlJ98mEgCDrIo/B+pskap4Qxq20vuxssL0nIXyM 1FoPlrTu8SuZrkViUSWmEICSB6UfZntIJDPxv9NSEjLKSkTCwIXna744W4zQQ/tHohohw2qc epCudGv1AhJBJS+UE8W+Lpt3e1fsMZQl/UIFpF3EQ3+6DkIHqk+nVe7zstcGbB/RUkHqwUCb km9Iv2B9YURrDW6XIF2jp+vAVuI78kLjXCTEBd8bzlBjt2BOTVaj4JZcdilKfNNr57H8Go+A IyVqsjjJ0LqkCdmG96lgJLUCcMztiJnTxxzLFSF4rQHKV14G8EQ+xMkx5We3QOWKGFHkf4JF zPCFD8O1978FbPEZ6JjnSR8Goeb5RKpGe3AfjHR7brS6jpxQaC8pGnjVBQzY3bXc1LSKWJ8N LHEOnKN5xBnwWpQv7pygxslnrNCzWCUijsqSQOFcihUEcZwNr6IwHBXBoR56pEiGk1u9Y8cZ VcJbQkj9Ok/0fNF1wYDlJS7gl20pD3YwZ2GIBPHH8FI+COOQmSTqpkN655H1qL4nfakXwu27 giSFbm0HupM7IuGm7fjigrkCDQRc2aU2ARAAysa169s6wds+2mg9oJTz0kDusRXca3pRiMKV 9YfpztMX9KK8F799gRtvjz8ZHVQlhr6NYHJmtsH5Y0iGYOL/6kUE56laB/C3cSJ0FOZN5Ov2 fROUWmEJod7oyHJW0mcGKGfHiuGo0Xs7bAcspxF5s8iysFr50nLGEqJJ7G6/jzcMuFwqhQ5z B3/hctD09nI5YPzJJrJiPxtJ3OV4wEziIW7Ff9rOwSDvMLbSfX/iJA7QRM81IuTVWBBljlG9 YkbPcyczINtqYAXFaKGaUM+TE3YnUDFsHgvpEm2MFC4NCcKFDgsAy8IOEYRCDXtkS2eopQvd rafP5jJ9aLXP/zbXlslY7dQ+QxQjus1W+V0eR09NDp83uaJ/EdtnveETyQqjrF+z4svdlRYF Xd3kyV91OC2r3fXX2uKHDuAQVI2jbAS2apnCJbCQJMQfULyAYXKf8iCGk7nC1y0tGGpQ7HxQ GW0KC86GQP8hrXYNVvhkFGuxGjp814U7eFfZUZICq3Lqk8rxi830+9noFCHU4egkRynULhCN M1R/A/itwBZsrZ4+I6vYejKizDvzm3e9sb+5CMQeX4Y1uLkYKT163hshJCGsJEIobmvLlqUh qkY3UFI293h8xv/b0bEbeILUWJn2c6GNWR3flbb4wYW968DZg3uvKnFkomA6XECwsAKDegUA EQEAAYkCNgQYAQgAIBYhBMtH1Wjy658Jc3PaAvGJhHoErZ0PBQJc2aU2AhsMAAoJEPGJhHoE rZ0PYdEP/0K9Nc7khSfCqvuyLnoV6ONkaGHfbjgNcjGj7n46nx9FQJpp36fVBYItJdFXEfbt riY7OnqS5voTDlpmS922xfk9gfG1TKGQrsHCKSj63LyIPweYdCFGvy5F/Ijn0eNeVuxJU48D gE3nfAygrDdjfgDy3E+iFNEbb1YJLXCTavA4ciX5IZ7W7uzWLC4m2u/3N2/phuPtRcRdszB+ kwHPnmPNX1Jqw84jLD+Nn8ideM4G6H3fqFS55GktB0wfMOgsnVDSyrFKnXMF/077W8ZUU9k/ TveBbBtYLxcwJyrVnARh97xUi9PUABK/K8djp+z/kBQCU+Umwii4vFoubh/vTE/09BRaY8jg tvTetzzeMoqsnRiEgFHO+RCUFVFrzG8X48zji44+Vs/Ocq4Rz1auHPGpVT7ksB7/1C3wWOIg D+rOfkLt+zr1QG2V/BT1O0qrAaxOOm3pj76OyYks/tcdERkXWIQhCamn2Wc4h7tWuGnCJHny AGRF93EEPoMXoa5YxE7ai6WIUJBnR892vEVL+tOMDc0uaOAxk9xfMTM9FICqLVzfxo4GUDhJ tVV72OP0MkjyR1JTKZ6zAS7e5CviHutd8m/ILFDCKxgl46mERGW87eolJEO2aAjR8LycuwD2 PApJHMoXVaQKApGJYYaUeJrYDbqVYBNRMoVllUFOGRE6
Message-ID: 
Date: Wed, 13 May 2020 13:00:53 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------8C6FD63437E03D947E097C38"
Content-Language: en-US
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.1 mimetype
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 17:00:57 -0000

This is a multi-part message in MIME format.
--------------8C6FD63437E03D947E097C38
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Currently OAuth 2 uses application/json as their main mimetype for JSON
responses.

This has at least two drawbacks:

 1. Content-negotiation is a good way to to version/alter behavior of
    endpoints/introduce extensions or modifications.
 2. In systems that use Web Linking, it's harder to use a generic link
    relationship to point to an OAuth2 endpoint.

I would like to define links in my system to point to endpoints where
users may log in (to the authorize endpoint), or log out (the revoke
endpoint).

In an ideal world, I would do this with a link such as:

Link: https://auth-server.example; rel=3D"authenticate";
type=3D"application/oauth21+json"

This allows a client both figure out in a generic manner the endpoints
are, and also what protocol is supported.

Is there a chance that a new mimetype could be registered for OAuth 2.1?
I believe this can be done in a manner that's both backwards compatible
with OAuth 2, by requiring clients and servers to support
'application/json'. For instance, a server can respond with
'application/json' if it didn't receive 'application/oauth21+json' in
neither a Content-Type nor Accept request header.

Evert


--------------8C6FD63437E03D947E097C38
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Currently OAuth 2 uses application/json as their main mimetype
      for JSON responses.

    
This has at least two drawbacks:

    
    
      
  1. Content-negotiation is a good way to to version/alter behavior
        of endpoints/introduce extensions or modifications.
    2. 
      
  2. In systems that use Web Linking, it's harder to use a generic
        link relationship to point to an OAuth2 endpoint.
    3. 
    

    
I would like to define links in my system to point to endpoints
      where users may log in (to the authorize endpoint), or log out
      (the revoke endpoint).

    
In an ideal world, I would do this with a link such as:

      

      Link: https://auth-server.example; rel="authenticate";
      type="application/oauth21+json"

    
This allows a client both figure out in a generic manner the
      endpoints are, and also what protocol is supported.

    
Is there a chance that a new mimetype could be registered for
      OAuth 2.1? I believe this can be done in a manner that's both
      backwards compatible with OAuth 2, by requiring clients and
      servers to support 'application/json'. For instance, a server can
      respond with 'application/json' if it didn't receive
      'application/oauth21+json' in neither a Content-Type nor Accept
      request header.

    
Evert

    

  


--------------8C6FD63437E03D947E097C38--


From nobody Wed May 13 11:43:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D27B3A077A for ; Wed, 13 May 2020 11:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-25Sc94maMp for ; Wed, 13 May 2020 11:43:13 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F39A3A0775 for ; Wed, 13 May 2020 11:43:13 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id o14so731950ljp.4 for ; Wed, 13 May 2020 11:43:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sXTOiZeovUCxQ8eiy8P2upXdewJqkUM7UoNa6lftY5E=; b=bxWOL9xdWsOry+5xCsCaw7RJoGM+SNiLwBb5FbymY1FHLHWj2lV56Hz/WLZv6h+7xm AjDtC86VgOw4iyp1uhUxfHQEmxnsJppBzavMTqmikfnX9ui4BljUDThqcCMAhhrPV3/v nYY+OYIEi+YUJzsnhi7PfnOR/2xCX1kQSOhoaxBZbCJCPwnySUoChpXlV4MNIf7UAnP6 oGfU8jqh/GmF2xaJu0wdQSySkdP6pcYeDoH5tLWJ6oWhrPBgTXx5nUYCSKVm4Lh5bzri Ir8zXt8CCnT1vuNi0ioxTM24tvS+f8LzL1nBDLZrhnc+ELJftwTJnOxTPDPkYlXGjfce 52KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sXTOiZeovUCxQ8eiy8P2upXdewJqkUM7UoNa6lftY5E=; b=t6BKrNafKQuWbfnmh5McZdu0J9Bmt6aQEErMeEyK3VMXZxmF1YR7zw2YtPyYm07evL pe9Xt7h+9lFVbWFGT/wZ98AnmAxCnfmqgj/5F+lSx5wDiyG+o/7fXjhALVqmvoZLLd0u VGvgp9s9CpWTbUQkwgbo04vI6NXfan13u4nM8IRo1xrI29pKX/vK1Icwr6Zy0Tc0Whjg lMhvLQN3dPPIV1ufhyR8N/hHHfNjqOu3kjah8SMjjoffDf8r7kYoeL8pdFfTfVemlYbe Awz6qmWk/PZvPnOBO/X65CnqyZVjg7twIzXG4BpuUqccTBX7VWBDbigmYqxgkhIS+stx Qipg==
X-Gm-Message-State: AOAM531OfNHSxoXsN0uT7ZBvu9VtYb0E5JVtYtGN0QmOSGSxkLqSK5L7 jfswwsD8i1kwg6p5qqdiX5nTGJeElNRcO5CGaD4yWo2UMAZhwMak0hjgbtC/OpnXS35alriTBKG 61XixA+L/4GDvIQ==
X-Google-Smtp-Source: ABdhPJzzZ7ADDPw7ZFb4nLtSqPlApwotT/OnGTgq2Ce6em72/xgj+2odhw7sWe2nQM4Bf0sppmfcU+ZpN3V0ZeQwsgY=
X-Received: by 2002:a2e:6a02:: with SMTP id f2mr294565ljc.96.1589395391580; Wed, 13 May 2020 11:43:11 -0700 (PDT)
MIME-Version: 1.0
References: <158937215806.9148.1182768951394743318@ietfa.amsl.com>
In-Reply-To: <158937215806.9148.1182768951394743318@ietfa.amsl.com>
From: Brian Campbell 
Date: Wed, 13 May 2020 12:42:45 -0600
Message-ID: 
To: IESG Secretary 
Cc: IETF-Announce , oauth 
Content-Type: multipart/alternative; boundary="000000000000b95ec605a58bf323"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 May 2020 18:43:15 -0000

--000000000000b95ec605a58bf323
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just wanted to note that there is a newer -01 revision of the document on
the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html

On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
wrote:

> The Web Authorization Protocol (oauth) Working Group will hold
> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna
> (16:00 to 17:00 UTC).
>
> Agenda:
> DPOP
> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>
> Information about remote participation:
> https://ietf.webex.com/ietf/j.php?MTID=3Dm2655406e74aa2b4e129a1b91a076f70=
b
>
> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

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

--000000000000b95ec605a58bf323
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Just wanted to note that there is a newer -01 revision of =
the document on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html=
 

On Wed, May 13, 2020 at 6:16 AM IESG Secretary <iesg-secretary@ietf.org> wrote:
The Web Authorization Protoc=
ol (oauth) Working Group will hold

a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna (=
16:00 to 17:00 UTC).



Agenda:

DPOP

https://tools.ietf.org/html/draft-ietf-oauth-dpo=
p-00



Information about remote participation:

https://ietf.webex.com/iet=
f/j.php?MTID=3Dm2655406e74aa2b4e129a1b91a076f70b



https://mailarchive.ietf.org=
/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/



_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announ=
ce






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000b95ec605a58bf323--


From nobody Wed May 13 22:03:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC1B3A0B3E for ; Wed, 13 May 2020 22:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=cBROqPH8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=idznWUao
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4RQtMPyvM_w for ; Wed, 13 May 2020 22:03:07 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967C23A0B3C for ; Wed, 13 May 2020 22:03:07 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id ACF095C9 for ; Thu, 14 May 2020 01:03:06 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 14 May 2020 01:03:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=WKYBgQb7RIteuqYqAXOCw7vzpt6UjU1korfI3LNi75s=; b=cBROqPH8+2aH gqdXSajwYyhn1nsi/WCL6VeiZO+MR9ay9dyJLyq+4yTjv+zKIurStyCpq7CSUngP uIZ9h1brD6UgzGF1NKMA2wQhkJGaY6LGsjFBC5pgS6QUrTDeNbIqWjyaMIfzM2AY 1l1ge3uoMHVVegDOURasK9DHdmVZvhs=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=WKYBgQb7RIteuqYqAXOCw7vzpt6UjU1korfI3LNi7 5s=; b=idznWUaosLY7l5jOsNyGxjVYGO5qVZcfaVpaS8ANaR7gsb4pm8knaEX3j aFSVjM9+LakCyZYrXV7KkGJHrwO36fcVFsPL+zOGmpvWYpvt1khNO7+w+u8hB6KI WhOu0MV2XhMKfie5jtkCfXY+N4cklZs5QxSnPCz7SENz/gYSkxTUNEGNdWUi8zJR YpEfmNPXEpZ7xHH0YGmQ+rqwAowYPuWfYjum/ySeli8SO9BEtNKKvtxrxOZu1064 biEC6bW4ZGuFcLTdXhNoIYGoFhkfZF+vvKSc6HfI+MFNZYHapQTShomCYUDxF1US qdJ2W/m11g01a3QITwZJXwH7HCTsw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleehgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucggtffrrghtthgvrhhnpeejudduheektdduhefgjeetueehtdelgedtffejve ejvddvvdfgtdefjeetvddugfenucfkphepjedtrddvgedriedvrddvtdejnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgvsegvvhgvrhhtph hothdrtghomh
X-ME-Proxy:    
Received: from [192.168.2.10] (toroon0954w-lp140-01-70-24-62-207.dsl.bell.ca [70.24.62.207]) by mail.messagingengine.com (Postfix) with ESMTPA id F2C3C3280060 for ; Thu, 14 May 2020 01:03:05 -0400 (EDT)
To: oauth@ietf.org
References:  
From: Evert Pot 
Autocrypt: addr=me@evertpot.com; keydata= mQINBFzZpTYBEACt3GNTWOSosId2/7G1EHYWfva4gF4kgOL+/pew0+I2wTCyFeDXti+CRE1o 5LoCpTSGHDWZokSELeA2PwNX1ls7c2sZ7AVKWKhBLBhPEVo6YzlTli/B747ryGfMikiWYCRa e/yBJtyRuWuS8ArxCpEROzcUqCGZu7Rqs9RzUfYS7WZ85ne3DeRxPCCBIIlhlRu2lasjByPs IpSI0YSIpq4M5fLqbVdTjfqbTBGw82pDwQwlxO3J0T07dnvpEEheYspkMj/EGXqVTrLuoRw0 D7yObXgr0bcjuf+km8cdfZktclqCg1YajiseBBObw9IQpWiIE0oIxA7mAti1wus3JLxAfqCI tgzBtwEPeg6tcfzeDI9gnSl904g2+ozS0uFI61YHA/j70IxgIwyzp8QDsj0nS83aqaZV8k2U FNCnbriMftMCD/+iudRxfzq4VThkhIgfR9ZsaTvdWGIsAxCZyjaUHFMOBafjCMNjePCg74yA JSwdHhi6mzIuIfVGqsKXmO4Khzgm+c2qVq7cym93yp6kqNXOge9ZjQ2q96HHa64wXoYlNYZU 0fkvjkANj9V7ZC4PnavRMQHeFsW+vqU38pIFSppsqpeBggvV4U2WRHt2NyrE3ta9h1XTs9w3 SWSTujpJ/XGqPm7YYnNPrKXn5uvjEJ+OKt4+trpP1juUc3LJ8wARAQABtBtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT6JAk4EEwEIADgWIQTLR9Vo8uufCXNz2gLxiYR6BK2dDwUCXNml NgIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDxiYR6BK2dDyHmD/0bufc/UhM76R8S NSpYAds83HKt3XgIGPl8CEMaz35bkvlNypVUvd0iLy1MFgDDyqdXuM840HWL0grCC+g1LA8K eeHSYBDYm+ATlEu09FCN6+TdDbWBA19vmLlJ98mEgCDrIo/B+pskap4Qxq20vuxssL0nIXyM 1FoPlrTu8SuZrkViUSWmEICSB6UfZntIJDPxv9NSEjLKSkTCwIXna744W4zQQ/tHohohw2qc epCudGv1AhJBJS+UE8W+Lpt3e1fsMZQl/UIFpF3EQ3+6DkIHqk+nVe7zstcGbB/RUkHqwUCb km9Iv2B9YURrDW6XIF2jp+vAVuI78kLjXCTEBd8bzlBjt2BOTVaj4JZcdilKfNNr57H8Go+A IyVqsjjJ0LqkCdmG96lgJLUCcMztiJnTxxzLFSF4rQHKV14G8EQ+xMkx5We3QOWKGFHkf4JF zPCFD8O1978FbPEZ6JjnSR8Goeb5RKpGe3AfjHR7brS6jpxQaC8pGnjVBQzY3bXc1LSKWJ8N LHEOnKN5xBnwWpQv7pygxslnrNCzWCUijsqSQOFcihUEcZwNr6IwHBXBoR56pEiGk1u9Y8cZ VcJbQkj9Ok/0fNF1wYDlJS7gl20pD3YwZ2GIBPHH8FI+COOQmSTqpkN655H1qL4nfakXwu27 giSFbm0HupM7IuGm7fjigrkCDQRc2aU2ARAAysa169s6wds+2mg9oJTz0kDusRXca3pRiMKV 9YfpztMX9KK8F799gRtvjz8ZHVQlhr6NYHJmtsH5Y0iGYOL/6kUE56laB/C3cSJ0FOZN5Ov2 fROUWmEJod7oyHJW0mcGKGfHiuGo0Xs7bAcspxF5s8iysFr50nLGEqJJ7G6/jzcMuFwqhQ5z B3/hctD09nI5YPzJJrJiPxtJ3OV4wEziIW7Ff9rOwSDvMLbSfX/iJA7QRM81IuTVWBBljlG9 YkbPcyczINtqYAXFaKGaUM+TE3YnUDFsHgvpEm2MFC4NCcKFDgsAy8IOEYRCDXtkS2eopQvd rafP5jJ9aLXP/zbXlslY7dQ+QxQjus1W+V0eR09NDp83uaJ/EdtnveETyQqjrF+z4svdlRYF Xd3kyV91OC2r3fXX2uKHDuAQVI2jbAS2apnCJbCQJMQfULyAYXKf8iCGk7nC1y0tGGpQ7HxQ GW0KC86GQP8hrXYNVvhkFGuxGjp814U7eFfZUZICq3Lqk8rxi830+9noFCHU4egkRynULhCN M1R/A/itwBZsrZ4+I6vYejKizDvzm3e9sb+5CMQeX4Y1uLkYKT163hshJCGsJEIobmvLlqUh qkY3UFI293h8xv/b0bEbeILUWJn2c6GNWR3flbb4wYW968DZg3uvKnFkomA6XECwsAKDegUA EQEAAYkCNgQYAQgAIBYhBMtH1Wjy658Jc3PaAvGJhHoErZ0PBQJc2aU2AhsMAAoJEPGJhHoE rZ0PYdEP/0K9Nc7khSfCqvuyLnoV6ONkaGHfbjgNcjGj7n46nx9FQJpp36fVBYItJdFXEfbt riY7OnqS5voTDlpmS922xfk9gfG1TKGQrsHCKSj63LyIPweYdCFGvy5F/Ijn0eNeVuxJU48D gE3nfAygrDdjfgDy3E+iFNEbb1YJLXCTavA4ciX5IZ7W7uzWLC4m2u/3N2/phuPtRcRdszB+ kwHPnmPNX1Jqw84jLD+Nn8ideM4G6H3fqFS55GktB0wfMOgsnVDSyrFKnXMF/077W8ZUU9k/ TveBbBtYLxcwJyrVnARh97xUi9PUABK/K8djp+z/kBQCU+Umwii4vFoubh/vTE/09BRaY8jg tvTetzzeMoqsnRiEgFHO+RCUFVFrzG8X48zji44+Vs/Ocq4Rz1auHPGpVT7ksB7/1C3wWOIg D+rOfkLt+zr1QG2V/BT1O0qrAaxOOm3pj76OyYks/tcdERkXWIQhCamn2Wc4h7tWuGnCJHny AGRF93EEPoMXoa5YxE7ai6WIUJBnR892vEVL+tOMDc0uaOAxk9xfMTM9FICqLVzfxo4GUDhJ tVV72OP0MkjyR1JTKZ6zAS7e5CviHutd8m/ILFDCKxgl46mERGW87eolJEO2aAjR8LycuwD2 PApJHMoXVaQKApGJYYaUeJrYDbqVYBNRMoVllUFOGRE6
Message-ID: <8af89787-6028-bb9a-abc8-bff66d166a08@evertpot.com>
Date: Thu, 14 May 2020 01:03:05 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 05:03:10 -0000

On 2020-05-10 10:20 a.m., Aaron Parecki wrote:

> Hi Beena,
>
> This sounds like a great use of the client credentials grant. The
> password grant is being removed from OAuth 2.0 by the Security Best
> Current Practice. Can you clarify what you've found useful about the
> password grant that the client credentials grant doesn't solve?

One nice benefit of the password grant, is that client_id is a nice,
general way to trace what application did the log in. Handy for audit
logs and if we ever find a security issue we could hypothetically
invalidate all passwords used by the client_id that introduced the issue.

The alternative is to introduce a custom parameter, but this is unlikely
to work easily with existing OAuth2 implementations.

So, I will miss "password".

Evert


From nobody Wed May 13 23:56:52 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB2C3A0BE1 for ; Wed, 13 May 2020 23:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN8Z4cb7m1pA for ; Wed, 13 May 2020 23:56:48 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374B53A0BE8 for ; Wed, 13 May 2020 23:56:48 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id g12so31112583wmh.3 for ; Wed, 13 May 2020 23:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=abgmHWOXYhGcAxlKfMhqGaZuwN13N1U0ALTyJvAcQWM=; b=0FDuTYwLYCJzA1avr0XMtHLj50SZcaBpuN0FrepCU7DzwyC40XhlhxfzFP8VSqckdv Kuwqmi/hwoxpptivrTmGPIDcTAcWmLNS1N05Ww4ln0ZrU/rWyndNNxERwxlat4B4r6MS a63r32POzvJkGOGaxmAyr9ZUoBUY37fw1NvycAbMsOUF26XQr5HOjGka3fl1o2I+olDd 05X9pTNowtGDyp2M45nPhL0hu/6W+INZoGnkyIHfVXEZgQCeW9yyO9/sH/Bt/XsAuEvX Bnpaw6Mx7y+xztfoJ38cI+LSgyWqo4khXrBrnvrshwpfB50SDKQgz8uoNtrwYzHUCqa8 rKJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=abgmHWOXYhGcAxlKfMhqGaZuwN13N1U0ALTyJvAcQWM=; b=iND4x/yWO0hwSU9XtCsfKMOQazto7adKSDHNg1cr/FzkNAcOyoH9+PqxKLXj/9wuYx YfrPGmwlLDWZ8nKc9sVNJZLrRpRpWP99TyKtwD4oMBo1q2/lXa0/BQQ4zjBhDETSSDpf V1IbnsIW2t/k09KvhHWjPOFfr5dSO++RQYRH2CFFw6ehwjmZ7jkihTna8T5ngUfCsxo6 q2a8Gttzq5j9C6rLST6BTTVNddATsKUMy4lmFoEKFa4VtRgPQ7fx9b0K5qv/xKs98MRW 9EO15q5IwZ0LZ1+YKxKmv/6oXmCu0a+by5cV//NqAHB604DkoD5WLg6V0nzjN7IBhLTL rm9Q==
X-Gm-Message-State: AGi0PubKdwot3hoIAzsqV7/WA9HzyNmh2PaJyijKFHQlBvWzZ6sArMxO wT51csiNqLcjMe/a1IqipbAWavvenuk=
X-Google-Smtp-Source: APiQypIXmby0zMVzWPD31sDjvhb4iwUYZFs3kOEEj0UeJ+R3B6jzN8z7YdaWt6l6uQgrrW6h/AIi5A==
X-Received: by 2002:a1c:27c7:: with SMTP id n190mr24341389wmn.68.1589439406257;  Wed, 13 May 2020 23:56:46 -0700 (PDT)
Received: from p200300eb8f301f8b1d4993d41b246345.dip0.t-ipconnect.de (p200300EB8F301F8B1D4993D41B246345.dip0.t-ipconnect.de. [2003:eb:8f30:1f8b:1d49:93d4:1b24:6345]) by smtp.gmail.com with ESMTPSA id t71sm40852370wmt.31.2020.05.13.23.56.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2020 23:56:45 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Thu, 14 May 2020 08:56:43 +0200
Cc: Aaron Parecki , Mike Jones 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net>
References: 
To: OAuth WG 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 06:56:50 -0000

Hi all,

I would also like to thank everybody for the substantial discussion. =20

The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of =
PKCE instead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don=E2=80=99t feel comfortable =
with recommending any mechanism that this WG is not responsible for and =
thus did not conduct the security threat analysis for. I think the =
better way for us as WG is to define the extension point for other =
mechanisms. The OpenID Foundation (or any other body) can then fill in =
and issue a statement that nonce (or another suitable mechanism) fulfils =
the requirements of the extension point.=20

Based on this considerations, I propose the following text for Section =
9.7:

Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers. Public clients MUST use the=20
"code_challenge=E2=80=9D with a transaction-specific value that is
securely bound to the client and the user agent in which the
transaction was started. Confidential clients MUST use=20
the =E2=80=9Ccode_challenge=E2=80=9D in the same way or other suitable =
mechanisms to=20
mitigate authorization code injection.=20

This text follows the logic in Section 4.1.2.1 and allows use of the =
nonce for confidential clients.

best regards,
Torsten.=20

> On 12. May 2020, at 02:21, Mike Jones =
 wrote:
>=20
> That works for me.  Thanks all for the useful back-and-forth that got =
us to this point of clarity.  I suspect many of us learned things along =
the way; I know that I did!
> =20
>                                                        Cheers,
>                                                        -- Mike
> =20
> From: Aaron Parecki =20
> Sent: Monday, May 11, 2020 4:55 PM
> To: OAuth WG 
> Cc: Neil Madden ; Mike Jones =

> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
> =20
> Thank you Neil.
> =20
> To address Mike's concerns in the previous threads, I would like to =
also update section 9.7 with the following text:
> =20
> Clients MUST prevent injection (replay) of authorization codes into =
the=20
> authorization response by attackers. The use of the `code_challenge`
> parameter is RECOMMENDED to this end. For confidential clients, the=20
> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be =
used=20
> instead of or in addition to the `code_challenge` parameter for this=20=

> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
> transaction-specific and securely bound to the client and the user =
agent=20
> in which the transaction was started.
> =20
> This change better clarifies the specific circumstances under which =
the "nonce" parameter is sufficient to protect against authorization =
code injection.
> =20
> Aaron Parecki
> =20
> On Mon, May 11, 2020 at 11:55 AM Neil Madden =
 wrote:
> I am happy with this proposed wording. Thanks for updating it.
> =20
> =E2=80=94 Neil
>=20
>=20
> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
> =20
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20
> =20
> We would like to propose the following text, which is a slight =
variation from the text Neil proposed. This would replace the paragraph =
in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) =
that begins with "If the client does not send the "code_challenge" in =
the request..."
> =20
> "An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways. See section 9.7 for details."
> =20
> Section 9.7 is where the nuances of PKCE vs nonce are described.
> =20
> As Neil described, we believe this will allow ASs to support both =
OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is =
the clarification of which threats, and changing to MUST instead of =
SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we =
are already describing the explicit exception to the rule, it's more =
clear as a MUST here.
> =20
> Aaron Parecki
> =20
> =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


From nobody Wed May 13 23:57:32 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525BB3A0BD4 for ; Wed, 13 May 2020 23:57:30 -0700 (PDT)
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrWChVaZpVHf for ; Wed, 13 May 2020 23:57:28 -0700 (PDT)
Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BEF3A0BE1 for ; Wed, 13 May 2020 23:57:28 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Z7o3jXwEMf1qNZ7o5jZeNg; Wed, 13 May 2020 23:57:27 -0700
X-CMAE-Analysis: v=2.3 cv=GON27dFK c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=SMEE0oRgF1s8rFqhd5MA:9 a=swtiq8cPB2_r5MFh:21 a=wpilc7wLf2bsV4Zh:21 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References:  
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUVOQkZRWmFvRUJDQUNu UDJZTURleDlmbmYrbmlMZ2xUSEdLdW95cFVTVktQUWVLREhIZUZRVnpoUmtlK0hCCkVaQndt QTlUa1ora0VoeXJOcWliRFBrUFlWUG1vMjN0TThtYk5jVFZRcXBtTjdOd2dNcHFrcWNBcU5z SXlCdHQKMDlEaldPUVZtNTdBM0sreXVYSTdTZE5FcmR0NzlwMnhRc2VPaHFTQzkrTGdXdXlo K21ac2wyb0ZENGdsRkZmSwpTQ01wMmpBVFhyQU1lR3ppZ1RuVytYZTB0Unpyd0ZOOXpxeWtL eGhVcTlvSGcxY052b0R0Znhnc2M5eXNWSGJ4Ck0vUE04bzlsZ2ozWVRRd0tNQmNDRmNsVHFv aGppN01MZlEwOGVRbythY0tUd0MxV1J6ZUx0OVBrbkd0M0M0VG0KdmRDbDBjMUJRVFRUTmlG OTZIdTRrYmFpQklic2Z4Sk9SOCtWQUJFQkFBRzBMRlpzWVdScGJXbHlJRVI2YUhWMgphVzV2 ZGlBOGRteGhaR2x0YVhKQVkyOXVibVZqZERKcFpDNWpiMjAraVFFK0JCTUJBZ0FvQlFKVUdX cUJBaHNqCkJRa0paZ0dBQmdzSkNBY0RBZ1lWQ0FJSkNnc0VGZ0lEQVFJZUFRSVhnQUFLQ1JB WjB2VXlPcXJpUWw2MkIvd08KTzBzMkpDL1F2TzZ3OWlTc1JoQ09hL0paaSt3TytsMDFWN2VH Q1ExY1lmMVcyNlk3aUtpVWxZNC9LeitjcjY5RApwTXRrdjNVcERUR2VqS0Vmc3BMVXh6NVZv M1Q0b0FLYlR0TnRWSVpML1h4SDMvSmhKNzE5Smo0ZUxvZTkvZGpLCmtHWVRYMk81Yk1rOFRw TzFERGpiSXc0cjlYS0k5WklrOTZ6bEtuWnZyZzdIbzdvT2wwWklmOEF6Y3ZkcVpFVW8KZ0R3 eXI4dXdPVStqSXl1eG1PVHRoZXBCelhDTmpqQmpuYzhJMS8vOVlwcEFJYUdKNW5uWGVsVlZE MS9keU9zegpvZ2VydnpGTkFORUlPdk52Q2Q5RzV1NGVzN3FrREtXS1k3L0xqMXRGK3RNckRU ck9oNkpxVUtiR05lVFVCOERsClB2SW9OeXFIVVlmQkVMZHB3MU5kdVFFTkJGUVphb0VCQ0FE YlBQTjJjOWl5aWYxcklpQTNpK09BTDIraldsVXcKeU0xaGNmdkE5enpZZ1FDRmJsTlprM2x6 a0d1a2tDZFNneUUzZGliQjdUclAvN2NQdVNWcDRzWi8vUGRTZVlTUAowTnBVUklpOU9xajRy M0RsUjF3YVI0ZzFwVlB3WEFoWXZoc1ZEMTlSRGRNYXNZQnFlbnUrRlhUdlJLVkIzZXJYCkJv WGtCcGhoVzRla01oK0UrMjFDcDJrYUlmM1ZFNGVLOTU2NXFGVmVtNTdDdFRDcWJwTThFbExi eVFlSEVsMDcKYlRyVThCQ25tQkpyOWJnK2gwR3A2czAyUGdlYndYa2lSNWlHZEFORHJZSEVt RGozWFlkVjhWRmxuNExSSmV1agpkR3NaUXBDOWFRdUZNaEQ1Njk2aWljZWxxSGRkTkxaMFNP TG5iOEl4Y1RuVTdISWp4TXBnUEJoUEFCRUJBQUdKCkFTVUVHQUVDQUE4RkFsUVphb0VDR3d3 RkNRbG1BWUFBQ2drUUdkTDFNanFxNGtLUE13ZitQK3pmSHQxL0wrbGEKMU9zelU4TVhsYXJD SHRSd3FmMFJPd1VWQjVQbUxxR1lxWFNVTjhxWEZZMzhuSUdOaHhEL0hBeDhJWnJsWjM0RgpU OUhINjJoQjN3bXd2ek8rSkRsNjN5cTAwT0pueXdBYVJVVFNJd2M2U25UUVRndTBRU0hpZE9H NHlFWFROWERNCkUxNGtPNUZ2ZGxwNmQyL3ZSRFo3b0JjdjZiWDdnMzFIVWU1bmFpNS9qWHFR Qmlra2dJSTZtc3Q0R0w4MDNXTGEKTlZ2QVViTGdlMjVndmdkQmRQZ01wY2tOeWEweXpvOXZI TVFEREFoTm9MMWVBWjlNcUcxcXQySVZWRTRkZ0hkTgpHVWJSRVoyOFd1ci8vZ05UcGFtYTZl UnJ4N2JPdVZ4ZjRldUtiTXhUTXZIQVA2YkpkSXVlblppVDZTWkpMYnBjCmhIaCtyZ1oyclE9 PQo9WVc3NAotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
Organization: Connect2id Ltd.
Message-ID: <66c55a6c-2c02-1c6f-c8e0-19ba57c98fa4@connect2id.com>
Date: Thu, 14 May 2020 09:57:22 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050306080606010502000209"
X-CMAE-Envelope: MS4wfGm5JMeyJlh34LZIFRpk5AnwFZfStlO4x7V8RPGCQh0CN4lVnP82YQpHZcRFmJXPIxbiPxGdJpfcGUEFbNdjrPTyYPFFSf5mvZRhzIkI174IjGPP0KEm FY3adwhAPLnnlGfzingTgbdQKYinqd/+WH00U9htcWjj5qUMScSQ7Z8y
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 06:57:30 -0000

This is a cryptographically signed message in MIME format.

--------------ms050306080606010502000209
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

+1 for require_request_objects AS metadata parameter.

The natural place for this parameter for me would be the JAR spec .

Vladimir

On 12/05/2020 09:27, Torsten Lodderstedt wrote:
> Hi all,
>
> I initially raised the question whether the AS should be able to requir=
e request objects for all clients (in the same way as we decided to let t=
he AS required PAR for all clients) but this topic was never discussed la=
ter on.=20
>
> I suggest to add a server metadata parameter =E2=80=9Crequire_request_o=
bjects=E2=80=9D so the AS can indicate its policy to clients.=20
>
> I think the best place to define this parameter would be JAR, if that i=
s not possible any longer, we could use a different PAR-specific name and=
 add it to PAR.
>
> What do you think?
>
> best regards,
> Torsten.=20
>
>> On 1. May 2020, at 17:56, Mike Jones  wrote:
>>
>> Works for me.
>>
>> =20
>>
>> From: OAuth  On Behalf Of Torsten Lodderstedt
>> Sent: Friday, May 1, 2020 2:51 AM
>> To: Brian Campbell 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
>>
>> =20
>>
>> Filip=C2=B4s proposal works for me.
>>
>> =20
>>
>> Are there any objections?
>>
>> =20
>>
>> Brian Campbell  schrieb=
 am Mo. 27. Apr. 2020 um 20:57:
>>
>> While there are certainly different permutations and contexts of use t=
hat could be imagine, I tend to agree with Filip here in not seeing a str=
ong need to define new PAR specific metadata around signing/encryption of=
 the request object.
>>
>> =20
>>
>> On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  wrot=
e:
>>
>> Considering there's going to be a setting that forces clients to use P=
AR (other mailinglist thread), then we should rely on the existing `reque=
st_object_signing_alg` presence to indicate a Request Object must be used=
 (as suggested by this upcoming OIDC Core errata), regardless of it being=
 PAR or JAR. I don't see the need for a PAR specific metadata, for one - =
implementations wouldn't be easily able to re-use of existing pipelines, =
two - yes the contexts differ but do you think clients will be using both=
 channels at the same time? And even if so, the Request Object is the sam=
e therefore its applicable to both channels the same.
>>
>>
>> Best,
>> Filip Skokan
>>
>> =20
>>
>> =20
>>
>> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  wrote:
>>
>> Hi all,=20
>>
>> this is one of the topics we quickly flipped through in the virtual me=
eting last week.=20
>>
>> I see the following open questions:
>> - Can the client require its instances to use request objects only.
>> - Are there further requirements on the properties of these objects? S=
igned only, Signed and encrypted, algorithms?=20
>> - Can an AS require ALL clients to use request objects only?=20
>> - Further requirements here as well?=20
>> - Is this tied to PAR or relevant for JAR as well?=20
>>
>> In my opinion, client as well as AS should be able to control enforced=
 use of request objects.=20
>>
>> I could imagine the setting for JAR request objects (=E2=80=9Crequest"=
 parameter) and request objects in the PAR context differ, as the first c=
ase goes through the user=E2=80=99s browser whereas the PAR case goes dir=
ect from client to AS via a TLS protected channel. I therefore feel the s=
ettings should be PAR specific.=20
>>
>> What do you think?
>>
>> best regards,
>> Torsten.=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
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privil=
eged material for the sole use of the intended recipient(s). Any review, =
use, distribution or disclosure by others is strictly prohibited...  If y=
ou have received this communication in error, please notify the sender im=
mediately by e-mail and delete the message and any file attachments from =
your computer. Thank you.
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov



--------------ms050306080606010502000209
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
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MTQwNjU3MjJaMC8G
CSqGSIb3DQEJBDEiBCBgscEFAf0gNrKZZNND6HeLlVlIYZrFjOUEUbyappxPgDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBADxn43Vk5db21sv3ZDK3EK50JC/msHScsQ4c09GVuGYOnA2S
cS+afDajX2jlb2wPl6zkL2fPm4Hzg//VfyPOWSMcNdvRuzKE4smVnxDRAXldihIqvCFz6tMV
3gunqnzIiWxA7e2kVDeZQEnSaCuRuuzD6KSuhjKpLRq/ZgzP2i9zYTGTuuNC67FZRTITFXQF
mYoaidloWxqaH92iF9OnZgHoasQ0IJaEIvl3hNgtZGtyEKubB1UL9DqPWG+7YcW+4m+VrRFv
T+Yi0Kby31fyEwsYUKaHMCtG2zUdq2ekdpk63HodxzxNaZK6YnXZ4XDGvzGByDZDBnJAn9WU
B2X+7v0AAAAAAAA=
--------------ms050306080606010502000209--


From nobody Thu May 14 00:37:58 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3266E3A03FF for ; Thu, 14 May 2020 00:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8mTKQPErfue for ; Thu, 14 May 2020 00:37:54 -0700 (PDT)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717463A03F6 for ; Thu, 14 May 2020 00:37:54 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id r10so909371pgv.8 for ; Thu, 14 May 2020 00:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UOi1DMQKJOpZvPvIZ4+QOoOgCKxWDMI2400vZJkUzyg=; b=lEwgZA8xgWB8UuYw8k5N+lpZYBZsZC6kNGCokcj0F2yX5I8SX4fURWNs6eHCyWmSUv E/TtWzyqzT0P4mrZ2vqGv05qFFr+ANbyBozGFMT0pCJNH1nmrD5ElncgiRQGTrcxGpW0 dMpdtOnKI8dZraRmt/wBXs6gbOgiGVrY6KYnfukBPmY2HXiWpC31/AcAU4JbW5NgVv1U MA8cU3iio2qktE3t6de5Bb/qYTLMikP6bSMeWqcCpu26acphzGc8EBlplzysgxNIdCal K58L3PSwEN5R8y6lBYWPUeFir3D8cvMezgFgHPhStpK6ZQDZ83ByPeeqFXrcAAheKwx3 XdAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UOi1DMQKJOpZvPvIZ4+QOoOgCKxWDMI2400vZJkUzyg=; b=d4KDeCdGTGmFU/maKEDOwefxTvXG7Uqp+zuw08Cghn/NMhVX7USdzwC+mKt9zXM1nA zCz5EsIBanvoAl6FtyVEfgbOXf38yqO3UsrHkHqNjZBTjUaLGrRvwOlLjZASAr8DTdWN DKXGsk4bCoFdFFjMi5eWQgu93HzSJThdkLH6P+nwNlQyXIhvCUNXTs+y2NB7eWCBinuS I/hR0NCJ7l6NzzCo87PNPK8JSIV2hP8Znzab3SLHcorxh095bOQm9iTbGn0baw9pImtD HquBJmk77oNbLd0Uo6In6nHAVM7z2dQL2A6gmU1J0Y0il8pr+uEDOcRK88JM1wljTRA0 /rRQ==
X-Gm-Message-State: AOAM5311QZYO+g0AT8bCmPZZYTjwJ8E1KXNhNAlJ72OPPO5T4eIYFivX z3/GRgdz50lPxGyACInsAaYuXQ9KBvI=
X-Google-Smtp-Source: ABdhPJzt9dca2fcPkQkJMy47lmDIrg6inaKHsTmxcLPIvkrPem705irXWCnh4t8i0QFFRR/BSFOAQA==
X-Received: by 2002:a63:5b07:: with SMTP id p7mr2956357pgb.218.1589441873767;  Thu, 14 May 2020 00:37:53 -0700 (PDT)
Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id c1sm1456079pgk.76.2020.05.14.00.37.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 00:37:52 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Nov Matake 
In-Reply-To: <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net>
Date: Thu, 14 May 2020 16:37:49 +0900
Cc: OAuth WG , Mike Jones 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com>
References:  <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 07:37:56 -0000

Hi,

Why not allowing public clients use "other suitable mechanisms=E2=80=9D =
then?
OAuth WG can allow both type of clients do so, then OIDF will define =
nonce as the alternative only for confidential clients.

> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =
=E3=81=AE=E3=83=A1=E3=83=BC=E3=
=83=AB:
>=20
> Hi all,
>=20
> I would also like to thank everybody for the substantial discussion. =20=

>=20
> The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:
>=20
> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of =
PKCE instead of requiring it (with a well-defined exception).
> - Given the latest findings re nonce I don=E2=80=99t feel comfortable =
with recommending any mechanism that this WG is not responsible for and =
thus did not conduct the security threat analysis for. I think the =
better way for us as WG is to define the extension point for other =
mechanisms. The OpenID Foundation (or any other body) can then fill in =
and issue a statement that nonce (or another suitable mechanism) fulfils =
the requirements of the extension point.=20
>=20
> Based on this considerations, I propose the following text for Section =
9.7:
>=20
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. Public clients MUST use the=20=

> "code_challenge=E2=80=9D with a transaction-specific value that is
> securely bound to the client and the user agent in which the
> transaction was started. Confidential clients MUST use=20
> the =E2=80=9Ccode_challenge=E2=80=9D in the same way or other suitable =
mechanisms to=20
> mitigate authorization code injection.=20
>=20
> This text follows the logic in Section 4.1.2.1 and allows use of the =
nonce for confidential clients.
>=20
> best regards,
> Torsten.=20
>=20
>> On 12. May 2020, at 02:21, Mike Jones =
 wrote:
>>=20
>> That works for me.  Thanks all for the useful back-and-forth that got =
us to this point of clarity.  I suspect many of us learned things along =
the way; I know that I did!
>>=20
>>                                                       Cheers,
>>                                                       -- Mike
>>=20
>> From: Aaron Parecki =20
>> Sent: Monday, May 11, 2020 4:55 PM
>> To: OAuth WG 
>> Cc: Neil Madden ; Mike Jones =

>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>=20
>> Thank you Neil.
>>=20
>> To address Mike's concerns in the previous threads, I would like to =
also update section 9.7 with the following text:
>>=20
>> Clients MUST prevent injection (replay) of authorization codes into =
the=20
>> authorization response by attackers. The use of the `code_challenge`
>> parameter is RECOMMENDED to this end. For confidential clients, the=20=

>> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be =
used=20
>> instead of or in addition to the `code_challenge` parameter for this=20=

>> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
>> transaction-specific and securely bound to the client and the user =
agent=20
>> in which the transaction was started.
>>=20
>> This change better clarifies the specific circumstances under which =
the "nonce" parameter is sufficient to protect against authorization =
code injection.
>>=20
>> Aaron Parecki
>>=20
>> On Mon, May 11, 2020 at 11:55 AM Neil Madden =
 wrote:
>> I am happy with this proposed wording. Thanks for updating it.
>>=20
>> =E2=80=94 Neil
>>=20
>>=20
>> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>>=20
>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20=

>>=20
>> We would like to propose the following text, which is a slight =
variation from the text Neil proposed. This would replace the paragraph =
in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) =
that begins with "If the client does not send the "code_challenge" in =
the request..."
>>=20
>> "An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways. See section 9.7 for details."
>>=20
>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>=20
>> As Neil described, we believe this will allow ASs to support both =
OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is =
the clarification of which threats, and changing to MUST instead of =
SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we =
are already describing the explicit exception to the rule, it's more =
clear as a MUST here.
>>=20
>> Aaron Parecki
>>=20
>>=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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu May 14 02:05:07 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D3D3A07F7 for ; Thu, 14 May 2020 02:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coil.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3IyL8ihw8lj for ; Thu, 14 May 2020 02:05:03 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631B83A07F6 for ; Thu, 14 May 2020 02:05:03 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id l20so404803ilj.10 for ; Thu, 14 May 2020 02:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:from:date:message-id:subject:to; bh=qcyF+FX9aaTmJzaNf5ilgDOsxKnJOKNIUy4OfwhtrAk=; b=AAcHtzLxu8JPzmfApBKRd6dNFvfqOCuGLA7pl6849W+gmXVI+RRCENYUVYY9ZzFA7D ZrzXSJS0qo3IYnr4ky6FcnxmP7FakPOLzkX7bAhXC3n2pF34Q8lIDhzTKGgCXtk4GBIG kfFL9tFCwe9tZqbSc6Tcp3Qlc7zXMZCaIC9s4JO8ozG9gDzCWZ4yt9v9K2Md6+bdGveW 1zX9NeEj2oqbJqegAArdbFosVdYYFh2WQFtKsU4pZmvwDL5WU26bp1vI0pbNvkF1ftdD xa2WM7IeVF253chtJd849/HT3bqX4Z1tXpwAdZBQ4foOQ6KDxEXuF3YdnA3/ILe73dsM EpOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qcyF+FX9aaTmJzaNf5ilgDOsxKnJOKNIUy4OfwhtrAk=; b=Dc46MxHzHI/zSCQauITNAts+nmBGRG+vYxmtVymHRYfiDA8B9pmfJueOYeyaYtRZ1h qgOMW62lEjzXcKrp6WJr274R6qh7D7kedkJP6TDmm1UKRX1KbjvDefXajyFQWAydh/VS 9bR0hFw4+VoxIZn8/QAqBDvL7IbGuLZjVm+D4XYRYQyZ0ziN9U7MZ1XGPMRE52lU1ChU d+G2zHiwWsbykEbaHS47hZiGPyTExjl50t32x5/NBfJtS5dJrNOIglG25N/ijcZlB1sK Sma2bpoHHmSntCt3grUeKgOhXRKAd+ima+jNIiG1hZnh5CDsZYuigpPKOWfP7E/+yTBU FRng==
X-Gm-Message-State: AOAM533f2Zsm62iryZmycBdAHvta3Bx/25wg8gxVbIBKpVy+5GGDIaiS qR+W2wGi4wm38acqNlttFXY2PL6WSMnaBHqjGf+9EFtDMR1JGA==
X-Google-Smtp-Source: ABdhPJxsasCaqzt2Ngaj+Ls/SiTvwpXPTL9dZVRtd2j6DTcy3jDZDvUxSEm/s+tKywSS2bUd/gv9Cju4eLADO9tlbk4=
X-Received: by 2002:a92:8747:: with SMTP id d7mr3673975ilm.235.1589447102149;  Thu, 14 May 2020 02:05:02 -0700 (PDT)
MIME-Version: 1.0
From: Matthew De Haast 
Date: Thu, 14 May 2020 11:04:50 +0200
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000e9caf505a597fd0b"
Archived-At: 
Subject: [OAUTH-WG] RAR - Client Credentials and Authorization Details
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 09:05:07 -0000

--000000000000e9caf505a597fd0b
Content-Type: text/plain; charset="UTF-8"

RFC6749 allows scopes to be presented at the token endpoint for cases like
client credentials grants.

It's not clear how this could be achieved with the current RAR spec though
when a Client using Client Credentials wants to request fine grained access
using authorization_details. Or should this even be possible?

Matt

--000000000000e9caf505a597fd0b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


RFC6749 allows scopes to be presented at the token en=
dpoint for cases like client credentials grants.

It's not clear how this could be achieved with the current RAR spec =
though when a Client using Client Credentials wants to request fine grained=
 access using authorization_details. Or should this even be possible?
=


Matt



--000000000000e9caf505a597fd0b--


From nobody Thu May 14 02:32:22 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7EE3A0854 for ; Thu, 14 May 2020 02:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYMMv-iqBxDN for ; Thu, 14 May 2020 02:32:17 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8487B3A0843 for ; Thu, 14 May 2020 02:32:17 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id z72so22027959wmc.2 for ; Thu, 14 May 2020 02:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNY6TMq2t0G8Y5BwI5DSerFhT/VhwI3Ztk+kMUDoEUM=; b=0sjv12+s2f/joNcytT6POSrdrGIhyhOBiUxWxUF5EfchaGxX4x3FQN/CX75CzVM5gb LgM5NwlxLp5R9nKyJCk+WSHOOBHMyP5rarM0U2eqDFZk10HlyNLPLvjWHSNDG7RSkuj6 dlgAjlo3hmpC7To8C6K00e9itgBtl3kk27s5dHyyApeY2czjWWzZcOXcpO6s3cfIdtbx lt3wzfkLH93cWp0egxGpMW27cwJXl0CSjfm5bm9doUd/llI/AzA5oh/FFxqw9RTcbAKi sTKxYx7s/oOnHMxO/4WCvxVh49erYdu4Xloc0TcMlr6Xkls23iFw6enhBYBSAw8D29AH kk5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNY6TMq2t0G8Y5BwI5DSerFhT/VhwI3Ztk+kMUDoEUM=; b=F85s7Z7GtTnlauJpq9RF/XpBBBa0Ad7lAx/Gph2J+rnd90B2DAbjft4RlfRdFeFSJB mkJi+J6PkQuB7U2LrlxGUCQjDZ8i0h4h/+2D6RcDeFDutF/TN3/edoZPWSARA0rsf+I9 piCA0tUEH0KV0D66514y0rHCpMwtpjZnc9O3Nd3JR2mOB5SzrG17Zg+JNYKPFLv9t9xN rkHkPjKBjJI0G+1x3Kp2kWV2+XPzgKoEf4THnHa4kfDGy+x3IDEXd6cH4fs7fwC8Mua2 gjYJYLIXxJIKGeeM8kUmBpFmIezRZPkUohTFiwQIxGvi2tSod7fMIcCs6zF6HTM/+sUB erRw==
X-Gm-Message-State: AGi0Pua+FMyjsNn9YEJ6VlwlCJ1s25xbfkl0QkQVQii2BQAHv+YoqFS4 dOPy/ciDHPCT2mJg1mfvLmV8K//FPGY=
X-Google-Smtp-Source: APiQypJODSw+uOYCIOvaPfncyiPkeeaXJaXtPfqAp7xFf10mAh+Md5zMVJJCdPCOz9ztu2WcaIDEBA==
X-Received: by 2002:a1c:541e:: with SMTP id i30mr16184802wmb.120.1589448735720;  Thu, 14 May 2020 02:32:15 -0700 (PDT)
Received: from p200300eb8f301f8b1d4993d41b246345.dip0.t-ipconnect.de (p200300EB8F301F8B1D4993D41B246345.dip0.t-ipconnect.de. [2003:eb:8f30:1f8b:1d49:93d4:1b24:6345]) by smtp.gmail.com with ESMTPSA id w13sm2808827wrm.28.2020.05.14.02.32.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 02:32:15 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com>
Date: Thu, 14 May 2020 11:32:14 +0200
Cc: OAuth WG , Mike Jones 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1887D983-7A43-41C3-AAAD-786AD749240A@lodderstedt.net>
References:  <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net> <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com>
To: Nov Matake 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 09:32:21 -0000

Are you aware of any suitable mechanism? I=E2=80=99m asking since from =
my perspective this clause is mainly intended to allow existing OpenID =
Connect deployments to use nonce instead of PKCE in combination with =
OAuth 2.1. It=E2=80=99s a compromise. I think we should not encourage =
others to invent their own OAuth security mechanisms.=20

> On 14. May 2020, at 09:37, Nov Matake  wrote:
>=20
> Hi,
>=20
> Why not allowing public clients use "other suitable mechanisms=E2=80=9D =
then?
> OAuth WG can allow both type of clients do so, then OIDF will define =
nonce as the alternative only for confidential clients.
>=20
>> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =
=E3=81=AE=E3=83=A1=E3=83=BC=E3=
=83=AB:
>>=20
>> Hi all,
>>=20
>> I would also like to thank everybody for the substantial discussion. =20=

>>=20
>> The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:
>>=20
>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of =
PKCE instead of requiring it (with a well-defined exception).
>> - Given the latest findings re nonce I don=E2=80=99t feel comfortable =
with recommending any mechanism that this WG is not responsible for and =
thus did not conduct the security threat analysis for. I think the =
better way for us as WG is to define the extension point for other =
mechanisms. The OpenID Foundation (or any other body) can then fill in =
and issue a statement that nonce (or another suitable mechanism) fulfils =
the requirements of the extension point.=20
>>=20
>> Based on this considerations, I propose the following text for =
Section 9.7:
>>=20
>> Clients MUST prevent injection (replay) of authorization codes into
>> the authorization response by attackers. Public clients MUST use the=20=

>> "code_challenge=E2=80=9D with a transaction-specific value that is
>> securely bound to the client and the user agent in which the
>> transaction was started. Confidential clients MUST use=20
>> the =E2=80=9Ccode_challenge=E2=80=9D in the same way or other =
suitable mechanisms to=20
>> mitigate authorization code injection.=20
>>=20
>> This text follows the logic in Section 4.1.2.1 and allows use of the =
nonce for confidential clients.
>>=20
>> best regards,
>> Torsten.=20
>>=20
>>> On 12. May 2020, at 02:21, Mike Jones =
 wrote:
>>>=20
>>> That works for me.  Thanks all for the useful back-and-forth that =
got us to this point of clarity.  I suspect many of us learned things =
along the way; I know that I did!
>>>=20
>>>                                                      Cheers,
>>>                                                      -- Mike
>>>=20
>>> From: Aaron Parecki =20
>>> Sent: Monday, May 11, 2020 4:55 PM
>>> To: OAuth WG 
>>> Cc: Neil Madden ; Mike Jones =

>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>=20
>>> Thank you Neil.
>>>=20
>>> To address Mike's concerns in the previous threads, I would like to =
also update section 9.7 with the following text:
>>>=20
>>> Clients MUST prevent injection (replay) of authorization codes into =
the=20
>>> authorization response by attackers. The use of the `code_challenge`
>>> parameter is RECOMMENDED to this end. For confidential clients, the=20=

>>> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY =
be used=20
>>> instead of or in addition to the `code_challenge` parameter for this=20=

>>> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST =
be
>>> transaction-specific and securely bound to the client and the user =
agent=20
>>> in which the transaction was started.
>>>=20
>>> This change better clarifies the specific circumstances under which =
the "nonce" parameter is sufficient to protect against authorization =
code injection.
>>>=20
>>> Aaron Parecki
>>>=20
>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden =
 wrote:
>>> I am happy with this proposed wording. Thanks for updating it.
>>>=20
>>> =E2=80=94 Neil
>>>=20
>>>=20
>>> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>>>=20
>>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20=

>>>=20
>>> We would like to propose the following text, which is a slight =
variation from the text Neil proposed. This would replace the paragraph =
in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) =
that begins with "If the client does not send the "code_challenge" in =
the request..."
>>>=20
>>> "An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways. See section 9.7 for details."
>>>=20
>>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>>=20
>>> As Neil described, we believe this will allow ASs to support both =
OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is =
the clarification of which threats, and changing to MUST instead of =
SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we =
are already describing the explicit exception to the rule, it's more =
clear as a MUST here.
>>>=20
>>> Aaron Parecki
>>>=20
>>>=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
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Thu May 14 03:09:54 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CB83A0887 for ; Thu, 14 May 2020 03:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k4GsNzMpOlN for ; Thu, 14 May 2020 03:09:51 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A695D3A07A4 for ; Thu, 14 May 2020 03:09:50 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id i15so3094168wrx.10 for ; Thu, 14 May 2020 03:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hBXuc5GWGwZBaBbfuuVFKcSDXnpuhnOozCHERPTk3CM=; b=ccfcJGBXrZmHUxhNTIQ8tnT0UjRobdlRUkMHAEl4JRK9XwiA5uDIdoNSWcP/0Ks84q Bo154gtvOYxOj7++B6mOWLeaKNOSqo8kTt5uRkhZkBFK28ul5nUaKo3ka2aXsN6iXD4y MhB082u2ZUubF87MEXwxMsN+CVjDuENjO+nTNpPGM2wfE50G9Ir7KXOTDW6ydMfEbQwO Wo6wj26z1bpKS5hKuuj4hkmdEE4oPyG4N3bZMn4a4HXvI7BU3erwRk0bwYyvAaGM40q4 dU/u8bpthPC2VLA0qE37yh/8boqfgqrbzosPLPpVgHCUmUBomMkKjburYsJpV50sQuwM AIdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hBXuc5GWGwZBaBbfuuVFKcSDXnpuhnOozCHERPTk3CM=; b=fasnG58V10ze7oPiKb5z5+cbnR5xr2vvGAPC0YlJKaxse8v2KpwMvUS8bmIbQLzLh+ ZKsIwn4bOeDWhIMdODSKutEg+3wUJAFFpcjyzD3zJ7T7/cGDmg1p7gxgi/0BLDFTSq0J OZaBrA93HcuLbrDcMEDgGS5nhZdgpjNN7tFrBNA/Wt7VLkY/m8yEv2X0z3yrH5pFHm4f +cRsHn2zdChaAK3dn96M6y4Ra3sknBnZalUxW+jBJt7w4Uy3xuxOqlUfF9RyIzzqAQci Kqiqhug9YWzsxnoQ5Gbz0avbhPw1G5V/RV3DJ+Wh7zTqYaqorIzsuvCTw7q5Y/OHuXnp Fapw==
X-Gm-Message-State: AOAM533ZuiTH0TnhARrL1s5GsPYbqvFOK4bhJTUUQQzXft81+JR2OmDz fxTHn8agwkYImoqQTGawb+1hbfSy0Kc=
X-Google-Smtp-Source: ABdhPJyIKaGfVo9zB8ib1mN13Nq5KwdUkMu2FbWDR/xlPmKlMso4tC64TAYB5LgpeoFB1iS1W82T8w==
X-Received: by 2002:a5d:448e:: with SMTP id j14mr4464436wrq.261.1589450988821;  Thu, 14 May 2020 03:09:48 -0700 (PDT)
Received: from p200300eb8f301f8b1d4993d41b246345.dip0.t-ipconnect.de (p200300EB8F301F8B1D4993D41B246345.dip0.t-ipconnect.de. [2003:eb:8f30:1f8b:1d49:93d4:1b24:6345]) by smtp.gmail.com with ESMTPSA id x184sm6621890wmg.38.2020.05.14.03.09.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 03:09:48 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Thu, 14 May 2020 12:09:47 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BBA99B3-EE92-48D3-B838-5DDF171C013C@lodderstedt.net>
References: 
To: Matthew De Haast 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] RAR - Client Credentials and Authorization Details
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 10:09:52 -0000

Sure. That's possible.=20

https://tools.ietf.org/html/draft-ietf-oauth-rar-01#section-3.1 states=20=


"The request parameter can be used to specify authorization
   requirements in all places where the "scope" parameter is used for
   the same purpose, examples include:

=E2=80=A6

Access token requests as specified in [RFC6749], if also used as
      authorization requests, e.g. in the case of assertion grant types
      [RFC7521]=E2=80=9D

I filed a ticket to also mention this in the token request section.=20

> On 14. May 2020, at 11:04, Matthew De Haast =
 wrote:
>=20
> RFC6749 allows scopes to be presented at the token endpoint for cases =
like client credentials grants.
>=20
> It's not clear how this could be achieved with the current RAR spec =
though when a Client using Client Credentials wants to request fine =
grained access using authorization_details. Or should this even be =
possible?
>=20
> Matt
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu May 14 03:18:36 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A43A08B5 for ; Thu, 14 May 2020 03:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jca4dN0SuQ8 for ; Thu, 14 May 2020 03:18:33 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE4C3A08B2 for ; Thu, 14 May 2020 03:18:32 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id n18so1131529pfa.2 for ; Thu, 14 May 2020 03:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ew0sq3IogX8LM37T305LbTB8Hxb4r9BepdkhB+0y7ZQ=; b=i1bGXoYuKoIdNqnMR52LsdTiLJLzfpD73dn6Xmzh+LX0MHHQJMRjz7H+xIV9XSKhCt 3ISbrodpQwdthyQdYvmUeuA2ctuNvzHLOWVQh6BJAUYILMj7FvQ9L2qwf0ZgCuOJ5wvC oOiNi2Z4MhDnVxowGupc+ZWRZE2e2pPncxd0VdsnvG2pWKGROPpIEUhd0CaL4+r8W6rB hChvz/BMDcDxuo2tIIx3gl4GBoTFVuLloq2s0qHOcux5D0Wox8ITQeilMzdYNXrgArSG 9LeAtTscZv0dkoNwnSpsnMOlk4cnNypnwjT0cS4uQMDrtAahmHqDSBijpwvW9Qiyq4Ky R4LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ew0sq3IogX8LM37T305LbTB8Hxb4r9BepdkhB+0y7ZQ=; b=ud4FRs8aLEXSXgE6Gwf8nrqIKq6fM7HXXTWy/iOgNsVbjN76ihonmHV7zsDZd1q0sG OwlZC8bapCYuvk1CjOmsjg1eRR6pIhm4sDQ5wiRBTXiNYrqNojbkOCZ6ypRVt/6azDLO S+w9PQd0JuJH681KrEulTcdh97dU3+bHfQP6O5Aigw/7lR7uJbukg70AU/tAxWMh1a5M AQQXor2nWr2NcvipctbJx4aWngJS5tMjsX39KCdMX+0bO7i2FXNzdSFSnWSOkm+tDP2l uHKbzNsVozYsx1tjVybyKyz/xl8pjmbEkDc043axmqOwCWQO6Djhj9N/9rdMZbX6DG8J BxOg==
X-Gm-Message-State: AOAM531tmpVXrGLhdQEo2ZXFWNm0b8Rl9zI6tpvNzIeYGmB5BDUxBGdk IOIJENpK6jrqFZBFtPipnvM=
X-Google-Smtp-Source: ABdhPJwp/wkSzEgOC3B1Wh2/0o0yVU3LMK2Q8yIADZyAWws17hfuYDcUyuj3AiMAkaZ8w0DZ4kxi/g==
X-Received: by 2002:a63:c90f:: with SMTP id o15mr3296666pgg.67.1589451511370;  Thu, 14 May 2020 03:18:31 -0700 (PDT)
Received: from [172.16.80.133] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id b20sm1932673pff.8.2020.05.14.03.18.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 03:18:30 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Nov Matake 
In-Reply-To: <1887D983-7A43-41C3-AAAD-786AD749240A@lodderstedt.net>
Date: Thu, 14 May 2020 19:18:27 +0900
Cc: OAuth WG , Mike Jones 
Content-Transfer-Encoding: quoted-printable
Message-Id: <23145A44-5232-4312-9E51-627DB0FAFB44@gmail.com>
References:  <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net> <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com> <1887D983-7A43-41C3-AAAD-786AD749240A@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 10:18:35 -0000

There is no specific mechanism right now.
But future developers won=E2=80=99t be able to read the reason why the =
extension point is given only for confidential clients.

> On May 14, 2020, at 18:32, Torsten Lodderstedt =
 wrote:
>=20
> Are you aware of any suitable mechanism? I=E2=80=99m asking since from =
my perspective this clause is mainly intended to allow existing OpenID =
Connect deployments to use nonce instead of PKCE in combination with =
OAuth 2.1. It=E2=80=99s a compromise. I think we should not encourage =
others to invent their own OAuth security mechanisms.=20
>=20
>> On 14. May 2020, at 09:37, Nov Matake  wrote:
>>=20
>> Hi,
>>=20
>> Why not allowing public clients use "other suitable mechanisms=E2=80=9D=
 then?
>> OAuth WG can allow both type of clients do so, then OIDF will define =
nonce as the alternative only for confidential clients.
>>=20
>>> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =
=E3=81=AE=E3=83=A1=E3=83=BC=E3=
=83=AB:
>>>=20
>>> Hi all,
>>>=20
>>> I would also like to thank everybody for the substantial discussion. =
=20
>>>=20
>>> The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:
>>>=20
>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of =
PKCE instead of requiring it (with a well-defined exception).
>>> - Given the latest findings re nonce I don=E2=80=99t feel =
comfortable with recommending any mechanism that this WG is not =
responsible for and thus did not conduct the security threat analysis =
for. I think the better way for us as WG is to define the extension =
point for other mechanisms. The OpenID Foundation (or any other body) =
can then fill in and issue a statement that nonce (or another suitable =
mechanism) fulfils the requirements of the extension point.=20
>>>=20
>>> Based on this considerations, I propose the following text for =
Section 9.7:
>>>=20
>>> Clients MUST prevent injection (replay) of authorization codes into
>>> the authorization response by attackers. Public clients MUST use the=20=

>>> "code_challenge=E2=80=9D with a transaction-specific value that is
>>> securely bound to the client and the user agent in which the
>>> transaction was started. Confidential clients MUST use=20
>>> the =E2=80=9Ccode_challenge=E2=80=9D in the same way or other =
suitable mechanisms to=20
>>> mitigate authorization code injection.=20
>>>=20
>>> This text follows the logic in Section 4.1.2.1 and allows use of the =
nonce for confidential clients.
>>>=20
>>> best regards,
>>> Torsten.=20
>>>=20
>>>> On 12. May 2020, at 02:21, Mike Jones =
 wrote:
>>>>=20
>>>> That works for me.  Thanks all for the useful back-and-forth that =
got us to this point of clarity.  I suspect many of us learned things =
along the way; I know that I did!
>>>>=20
>>>>                                                     Cheers,
>>>>                                                     -- Mike
>>>>=20
>>>> From: Aaron Parecki =20
>>>> Sent: Monday, May 11, 2020 4:55 PM
>>>> To: OAuth WG 
>>>> Cc: Neil Madden ; Mike Jones =

>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>>=20
>>>> Thank you Neil.
>>>>=20
>>>> To address Mike's concerns in the previous threads, I would like to =
also update section 9.7 with the following text:
>>>>=20
>>>> Clients MUST prevent injection (replay) of authorization codes into =
the=20
>>>> authorization response by attackers. The use of the =
`code_challenge`
>>>> parameter is RECOMMENDED to this end. For confidential clients, the=20=

>>>> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY =
be used=20
>>>> instead of or in addition to the `code_challenge` parameter for =
this=20
>>>> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST =
be
>>>> transaction-specific and securely bound to the client and the user =
agent=20
>>>> in which the transaction was started.
>>>>=20
>>>> This change better clarifies the specific circumstances under which =
the "nonce" parameter is sufficient to protect against authorization =
code injection.
>>>>=20
>>>> Aaron Parecki
>>>>=20
>>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden =
 wrote:
>>>> I am happy with this proposed wording. Thanks for updating it.
>>>>=20
>>>> =E2=80=94 Neil
>>>>=20
>>>>=20
>>>> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>>>>=20
>>>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20=

>>>>=20
>>>> We would like to propose the following text, which is a slight =
variation from the text Neil proposed. This would replace the paragraph =
in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) =
that begins with "If the client does not send the "code_challenge" in =
the request..."
>>>>=20
>>>> "An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways. See section 9.7 for details."
>>>>=20
>>>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>>>=20
>>>> As Neil described, we believe this will allow ASs to support both =
OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is =
the clarification of which threats, and changing to MUST instead of =
SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we =
are already describing the explicit exception to the rule, it's more =
clear as a MUST here.
>>>>=20
>>>> Aaron Parecki
>>>>=20
>>>>=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
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20


From nobody Thu May 14 07:29:50 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1E23A0AB4 for ; Thu, 14 May 2020 07:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level: 
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh0ZghnuK2WM for ; Thu, 14 May 2020 07:29:47 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335B13A0AB0 for ; Thu, 14 May 2020 07:29:46 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d55 with ME id eeVj220094FMSmm03eVjM3; Thu, 14 May 2020 16:29:44 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 14 May 2020 16:29:44 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org, Vittorio Bertocci 
References: 
From: Denis 
Message-ID: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr>
Date: Thu, 14 May 2020 16:29:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9DE4E1B69B1BDCC34C1FCC14"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 14:29:49 -0000

This is a multi-part message in MIME format.
--------------9DE4E1B69B1BDCC34C1FCC14
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The current version of this draft is 
"draft-ietf-oauth-access-token-jwt-07" issued on April the 27 th.

This means that comments sent later on on the list have not been 
incorporated in this draft.
In particular, this one sent on April the 28 th:

*1) *The title of this spec. is:

    JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

So, this spec. is supposed to be targeted to OAuth *2.0. *

However, the header at the top of the page omits to mention it.

Currently, it is :

    Internet-Draft       OAuth Access Token JWT Profile           April 2020

It should rather be:

    Internet-Draft       OAuth *2.0* Access Token JWT Profile April 2020

It has been acknowledged by Vittorio on April, the 29 th:

/> The title of this spec./

Fixed, thanks!

This means that the draft document currently available on the IETF 
server is not reflecting the agreed comments.

Since then, I questioned myself how a client would be able to request an 
access token that would be
*strictly compliant with this Profile*.

For doing this exercise, I took a look at section 3 on pages 6 to 8. To 
summarize my findings:

  * the request MAY include a "resource" parameter. If the request does
    not include a "resource" parameter,
    the authorization server MUST use in the "aud" claim a default
    resource indicator.
  * the request MAY include "scope" parameter. If a "scope" parameter is
    present in the request,
    the authorization server SHOULD use it to infer the value of the
    default resource indicator to be used in the "aud" claim.

It seems to mean that if the request includes no "resource" parameter 
and no "scope" parameter, the access token will necessarily
include the "sub" claim.

If in the request, there would be present a parameter meaning "I want a 
token compliant with *this OAuth 2.0 profile*",
then there would be no problem, but this is not the case.

In the future, if additional parameters are included in the request, 
will the "sub" claim necessarily be present in the access token ?
If yes, this may be a privacy concern.

On the list there have been requirements for not making the "sub" 
parameter mandatory.

This point needs to be addressed and solved one way or another.

Denis

> All,
>
> Based on the 3rd WGLC, we believe that we have consensus to move this 
> document forward.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>
> We will be working on the shepherd write-up and then submit the 
> document to the IESG soon.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------9DE4E1B69B1BDCC34C1FCC14
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
The current version of
          this draft is
          "draft-ietf-oauth-access-token-jwt-07" issued on April the 27
          th.

          

          This means that comments sent later on on the list have not
          been incorporated
          in this draft. 

          In particular, this one sent on April the 28 th:

          

          1) The title of this spec. is: 

        
      
JSON Web Token (JWT) Profile for OAuth 2.0
            Access Tokens

          

      
          So, this spec. is supposed to be targeted to OAuth 2.0.  

          

          However, the header at the top of the page
          omits to mention it. 

          

          Currently, it is : 

        
      
Internet-Draft       OAuth Access Token
            JWT Profile           April
            2020

          

      It
          should rather be:

        
      
Internet-Draft       OAuth 2.0 Access
            Token JWT Profile          
            April 2020

          

      It
          has been acknowledged by Vittorio on April, the 29 th:

          

          > The title of this spec.

        

          Fixed, thanks!

        

    


        

    
This means that the
          draft document currently available on the IETF server is
          not reflecting the agreed comments.

          

          Since then, I questioned myself how a client would be able to
          request an access
          token that would be 

          strictly compliant with this Profile. 

          

          For doing this exercise, I
          took a look at section 3 on pages 6 to 8. To summarize my
          findings:

        
      
    
        
  • 
              the request MAY include a "resource" parameter. If the
              request does
              not include a "resource" parameter, 
    
              the authorization server MUST use
              in the "aud" claim a default resource indicator.
    • 
        
  • 
              the request MAY include "scope" parameter. If a "scope"
              parameter is present in the request, 
    
              the authorization server SHOULD use it to
              infer the value of the default resource indicator to be
              used in the
              "aud" claim.
    • 
      

      
          It seems to mean that if the request includes no "resource"
          parameter
          and no "scope" parameter, the access token will necessarily 

          include the "sub" claim. 

          

          If in the request, there would be present a parameter meaning
          "I want a token compliant with this OAuth 2.0 profile",
          

          then there would be no problem, but this is not the case.

    


        

    
In the future, if additional parameters
            are included
            in the request, will the "sub" claim necessarily be present
            in the
            access token ? 

            If yes, this may be a privacy concern.

          

    

          

          On the list there have been requirements for not making the
          "sub"
          parameter mandatory.

          

          This point needs to be addressed and solved one way or
          another.

          

        

    
Denis

    

    


    

    

      
      
All,
        


        

        
Based on the 3rd WGLC, we believe that we have consensus to
          move this document forward.

        
        


        

        
We will be working on the shepherd write-up and then submit
          the document to the IESG soon.

        


        

        
Regards,

        
 Rifaat & Hannes

        


        

      

      

      

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


    

    


    

  


--------------9DE4E1B69B1BDCC34C1FCC14--


From nobody Thu May 14 07:55:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4B53A0AA2 for ; Thu, 14 May 2020 07:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfiCDLYVbEBW for ; Thu, 14 May 2020 07:55:11 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E6C3A0A96 for ; Thu, 14 May 2020 07:55:11 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id g4so3871557ljl.2 for ; Thu, 14 May 2020 07:55:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=mHetsZlfGgGKtPt3BFw40YsaeTpRs5PNzeKKNZ+QtJw=; b=lFRUYlkWDOxJ7GnllroG5aRiGdDqCEdclW6XvvGubsW3eEjJ/u+33DN4oLm/kWpihl UOtS+mw8cTa9yg9UcZMMAOdepeFj/9+uQ5/VufIO/4Yj71+qVPmtVEf7BvFpndMKnizC LxDIJXohKSKT7xGvqOlJaNmCfK+FE6D+r+GIfdkxa7R4BT45CU/xhET0gb0PX0iyC6Kg YNJbRefXajKFixxl/CONr5/LkeuADl7fw5fR5nGen8ca9unm7nHPvpiNmjMF6XcDpQAx FKWKD+UxGg4JyJBIIUKgeXTgvB5eCxxDgQA4Tv/gXN6eySiPxUIZ6eqPKyGNuR3YJiEY p2kA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=mHetsZlfGgGKtPt3BFw40YsaeTpRs5PNzeKKNZ+QtJw=; b=lYvwXaEYf/HXnmhZnPaTOvwfsMIgCVMlXvrtYM07eMIQWc7/lUN102NnRdPFZ62RfG Po7jIuFJq0wMb4+m0JyRu608kc73BFBwjyWgjn4zlDTGwrklGhwtkmxNusXNmmc+JWsm izTPJV+X9JnAHCIo6To4fUMVZprvSBia4mApslrE2x8BMcXk8HY56enVLy6ISBW3mKoI 1SBNVkWmkDuryx8qmiRlJpfUITGwOA0MOI7z5cWqJFXvrFox/kBItgIhdHgR1jyYxEJS 22XeKWxTw5LgJxMyM+soXOVXxbr25SEwvzImOsYyMU2OTCNc34MKhTqxVwtQPrOO7gOQ ntng==
X-Gm-Message-State: AOAM532ugMw/2gbVZXXKqeweanDqR4CEVSO95qQuJXqGgJn92Xd6pH8K T8bmhGvOVs0wxwRRaefFFMcAAMM3wf83+vWi1odQ9Q==
X-Google-Smtp-Source: ABdhPJwUetiLANRnsGSitwccnIFtH3DdUYMOtybcgaMgSDaJrAGR/7KODhey9/TkpOmHsYL/kJ+oqhXJ8+jF/h/S0l4=
X-Received: by 2002:a05:651c:112c:: with SMTP id e12mr3074583ljo.127.1589468109115;  Thu, 14 May 2020 07:55:09 -0700 (PDT)
MIME-Version: 1.0
References:  <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr>
In-Reply-To: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr>
Reply-To: Vittorio@auth0.com
From: Vittorio Bertocci 
Date: Thu, 14 May 2020 07:54:57 -0700
Message-ID: 
To: Denis 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000006acc105a59ce2c4"
Archived-At: 
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 14:55:15 -0000

--00000000000006acc105a59ce2c4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Denis, the change you mentioned is basically a typo, which I did fix but
did not publish a new draft for- that doesn=E2=80=99t change the substance =
of the
consensus (and is something that will be fixed in the subsequent phases of
the process).
Whether the sub should be mandatory has been discussed for two reasons:

- as a way of distinguishing whether the token was obtained on behalf of a
user or an application identity, by omitting it in the latter case. We had
extensive discussions following IETF105 and concluded that not enough
people were interested in that scenario. I kept that discussion open for a
long time.
- for privacy concerns. Those has been debated and your position failed to
gather momentum.

Some of the recent discussions on sub didn=E2=80=99t pick up on the discuss=
ions
above and didn=E2=80=99t bring new arguments that weren=E2=80=99t already d=
ebated.
Nonetheless I did my best to provide context and pointer to the past
discussions when answering the concerns. In other words, those discussions
didn=E2=80=99t appear to change the consensus achieved on the matter. We ha=
ve 3
last calls, I don=E2=80=99t think the chairs changed the status of the docu=
ment
lightly.



On Thu, May 14, 2020 at 07:29 Denis  wrote:

> The current version of this draft is
> "draft-ietf-oauth-access-token-jwt-07" issued on April the 27 th.
>
> This means that comments sent later on on the list have not been
> incorporated in this draft.
> In particular, this one sent on April the 28 th:
>
> *1) *The title of this spec. is:
>
> JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
>
> So, this spec. is supposed to be targeted to OAuth *2.0. *
>
> However, the header at the top of the page omits to mention it.
>
> Currently, it is :
>
> Internet-Draft       OAuth Access Token JWT Profile           April 2020
>
> It should rather be:
>
> Internet-Draft       OAuth *2.0* Access Token JWT Profile           April
> 2020
>
> It has been acknowledged by Vittorio on April, the 29 th:
>
> *> The title of this spec.*
>
> Fixed, thanks!
>
> This means that the draft document currently available on the IETF server
> is not reflecting the agreed comments.
>
> Since then, I questioned myself how a client would be able to request an
> access token that would be
> *strictly compliant with this Profile*.
>
> For doing this exercise, I took a look at section 3 on pages 6 to 8. To
> summarize my findings:
>
>    - the request MAY include a "resource" parameter. If the request does
>    not include a "resource" parameter,
>    the authorization server MUST use in the "aud" claim a default
>    resource indicator.
>    - the request MAY include "scope" parameter. If a "scope" parameter is
>    present in the request,
>    the authorization server SHOULD use it to infer the value of the
>    default resource indicator to be used in the "aud" claim.
>
> It seems to mean that if the request includes no "resource" parameter and
> no "scope" parameter, the access token will necessarily
> include the "sub" claim.
>
> If in the request, there would be present a parameter meaning "I want a
> token compliant with *this OAuth 2.0 profile*",
> then there would be no problem, but this is not the case.
>
> In the future, if additional parameters are included in the request, will
> the "sub" claim necessarily be present in the access token ?
> If yes, this may be a privacy concern.
>
> On the list there have been requirements for not making the "sub"
> parameter mandatory.
>
> This point needs to be addressed and solved one way or another.
>
>
> Denis
>
> All,
>
> Based on the 3rd WGLC, we believe that we have consensus to move this
> document forward.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>
> We will be working on the shepherd write-up and then submit the document
> to the IESG soon.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>

--00000000000006acc105a59ce2c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Denis, the change you mentioned is basically a typo,=
 which I did fix but did not publish a new draft for- that doesn=E2=80=99t =
change the substance of the consensus (and is something that will be fixed =
in the subsequent phases of the process).
Whet=
her the sub should be mandatory has been discussed for two reasons:

- as a way of distinguishing wh=
ether the token was obtained on behalf of a user or an application identity=
, by omitting it in the latter case. We had extensive discussions following=
 IETF105 and concluded that not enough people were interested in that scena=
rio. I kept that discussion open for a long time.
- =
for privacy concerns. Those has been debated and your position failed to ga=
ther momentum.

Some of t=
he recent discussions on sub didn=E2=80=99t pick up on the discussions abov=
e and didn=E2=80=99t bring new arguments that weren=E2=80=99t already debat=
ed. Nonetheless I did my best to provide context and pointer to the past di=
scussions when answering the concerns. In other words, those discussions di=
dn=E2=80=99t appear to change the consensus achieved on the matter. We have=
 3 last calls, I don=E2=80=99t think the chairs changed the status of the d=
ocument lightly.



On Thu, May 14, 2020 at 07:29 Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
The current version of
          this draft is
          "draft-ietf-oauth-access-token-jwt-07" issued on April =
the 27
          th.

          

          This means that comments sent later on on the list have not
          been incorporated
          in this draft. 

          In particular, this one sent on April the 28 th:

          

          1) The title of this spec. is: 

        
      
JSON Web Token (JWT) Profile for OAuth 2.0
            Access Tokens

          
      
          So, this spec. is supposed to be targeted to OAuth 2.0. =C2=A0

          

          However, the header at the top of the page
          omits to mention it. 

          

          Currently, it is : 

        
      
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth Access =
Token
            JWT Profile=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 April
            2020

          
      It
          should rather be:

        
      
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0<=
/b> Access
            Token JWT Profile=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
            April 2020=


          
      It
          has been acknowledged by Vittorio on April, the 29 th:

          

          > The title of this spec.

        

          Fixed, thanks!

        

    


        

    
This means that the
          draft document currently available on the IETF server is
          not reflecting the agreed comments.

          

          Since then, I questioned myself how a client would be able to
          request an access
          token that would be 

          strictly compliant with this Profile. 

          

          For doing this exercise, I
          took a look at section 3 on pages 6 to 8. To summarize my
          findings:

        
      
    
        
  • 
              the request MAY include a "resource" parameter. If =
the
              request does
              not include a "resource" parameter, 
    
              the authorization server MUST use
              in the "aud" claim a default resource indicator.
    • 
        
  • 
              the request MAY include "scope" parameter. If a &qu=
ot;scope"
              parameter is present in the request, 
    
              the authorization server SHOULD use it to
              infer the value of the default resource indicator to be
              used in the
              "aud" claim.
    • 
      

      
          It seems to mean that if the request includes no "resource&q=
uot;
          parameter
          and no "scope" parameter, the access token will necessa=
rily 

          include the "sub" claim. 

          

          If in the request, there would be present a parameter meaning
          "I want a token compliant with this OAuth 2.0 profile=
",
          

          then there would be no problem, but this is not the case.<=
/font>

    


        

    
In the future, if additional=
 parameters
            are included
            in the request, will the "sub" claim necessarily be p=
resent
            in the
            access token ? 

            If yes, this may be a privacy concern.

          

    

          

          On the list there have been requirements for not making the
          "sub"
          parameter mandatory.

          

          This point needs to be addressed and solved one way or
          another.
=


          

        

    
Denis

    

    


    

    

     =20
      
All,
        


        

        
Based on the 3rd WGLC, we believe=C2=A0that we have consensus=
=C2=A0to
          move this document forward.

        
        


        

        
We will be working on the shepherd write-up and then submit
          the document to the IESG soon.

        


        

        
Regards,

        
=C2=A0Rifaat & Hannes

        


        

      

      

      

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


    

    


    

  





--00000000000006acc105a59ce2c4--


From nobody Thu May 14 08:29:14 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4DB3A0BA5 for ; Thu, 14 May 2020 08:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level: 
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G67h-7WS39nP for ; Thu, 14 May 2020 08:29:10 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5B53A07C5 for ; Thu, 14 May 2020 08:29:09 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d55 with ME id efV62201C4FMSmm03fV7pg; Thu, 14 May 2020 17:29:07 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 14 May 2020 17:29:07 +0200
X-ME-IP: 86.238.65.197
To: Vittorio@auth0.com
Cc: oauth@ietf.org
References:  <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> 
From: Denis 
Message-ID: <97a76ac8-766a-ca79-a0a1-0d5893ee3fd2@free.fr>
Date: Thu, 14 May 2020 17:29:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------85D0D26396AFC0A13C52081C"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 15:29:13 -0000

This is a multi-part message in MIME format.
--------------85D0D26396AFC0A13C52081C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Vittorio,

I raised the following question:

    In the future, if additional parameters are included in the request,
    will the "sub" claim necessarily be present in the access token ?

The answer to this question does not seem to be present in the draft. 
Would you be able to provide an answer ?

Denis

> Denis, the change you mentioned is basically a typo, which I did fix 
> but did not publish a new draft for- that doesn’t change the substance 
> of the consensus (and is something that will be fixed in the 
> subsequent phases of the process).
> Whether the sub should be mandatory has been discussed for two reasons:
>
> - as a way of distinguishing whether the token was obtained on behalf 
> of a user or an application identity, by omitting it in the latter 
> case. We had extensive discussions following IETF105 and concluded 
> that not enough people were interested in that scenario. I kept that 
> discussion open for a long time.
> - for privacy concerns. Those has been debated and your position 
> failed to gather momentum.
>
> Some of the recent discussions on sub didn’t pick up on the 
> discussions above and didn’t bring new arguments that weren’t already 
> debated. Nonetheless I did my best to provide context and pointer to 
> the past discussions when answering the concerns. In other words, 
> those discussions didn’t appear to change the consensus achieved on 
> the matter. We have 3 last calls, I don’t think the chairs changed the 
> status of the document lightly.
>
>
>
> On Thu, May 14, 2020 at 07:29 Denis  > wrote:
>
>     The current version of this draft is
>     "draft-ietf-oauth-access-token-jwt-07" issued on April the 27 th.
>
>     This means that comments sent later on on the list have not been
>     incorporated in this draft.
>     In particular, this one sent on April the 28 th:
>
>     *1) *The title of this spec. is:
>
>         JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
>
>     So, this spec. is supposed to be targeted to OAuth *2.0. *
>
>     However, the header at the top of the page omits to mention it.
>
>     Currently, it is :
>
>         Internet-Draft OAuth Access Token JWT Profile           April 2020
>
>     It should rather be:
>
>         Internet-Draft OAuth *2.0* Access Token JWT Profile          
>         April 2020
>
>     It has been acknowledged by Vittorio on April, the 29 th:
>
>     /> The title of this spec./
>
>     Fixed, thanks!
>
>     This means that the draft document currently available on the IETF
>     server is not reflecting the agreed comments.
>
>     Since then, I questioned myself how a client would be able to
>     request an access token that would be
>     *strictly compliant with this Profile*.
>
>     For doing this exercise, I took a look at section 3 on pages 6 to
>     8. To summarize my findings:
>
>       * the request MAY include a "resource" parameter. If the request
>         does not include a "resource" parameter,
>         the authorization server MUST use in the "aud" claim a default
>         resource indicator.
>       * the request MAY include "scope" parameter. If a "scope"
>         parameter is present in the request,
>         the authorization server SHOULD use it to infer the value of
>         the default resource indicator to be used in the "aud" claim.
>
>     It seems to mean that if the request includes no "resource"
>     parameter and no "scope" parameter, the access token will necessarily
>     include the "sub" claim.
>
>     If in the request, there would be present a parameter meaning "I
>     want a token compliant with *this OAuth 2.0 profile*",
>     then there would be no problem, but this is not the case.
>
>     In the future, if additional parameters are included in the
>     request, will the "sub" claim necessarily be present in the access
>     token ?
>     If yes, this may be a privacy concern.
>
>     On the list there have been requirements for not making the "sub"
>     parameter mandatory.
>
>     This point needs to be addressed and solved one way or another.
>
>
>     Denis
>
>>     All,
>>
>>     Based on the 3rd WGLC, we believe that we have consensus to move
>>     this document forward.
>>     https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>>
>>     We will be working on the shepherd write-up and then submit the
>>     document to the IESG soon.
>>
>>     Regards,
>>      Rifaat & Hannes
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org  
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>


--------------85D0D26396AFC0A13C52081C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Vittorio,

    


      

    
I raised the following question:

    

      
In the future, if
              additional parameters are included in the request, will
              the "sub" claim necessarily be present in the access token
              ? 

            

    

    
The answer to this
            question does not seem to be present in the draft. Would you
            be able to provide an answer ?

    


          

    
Denis

    


          

    

      
      

        
Denis, the change you mentioned is basically a
          typo, which I did fix but did not publish a new draft for-
          that doesn’t change the substance of the consensus (and is
          something that will be fixed in the subsequent phases of the
          process).

      

      
Whether the sub should be mandatory has been
        discussed for two reasons:

      


      

      
- as a way of distinguishing whether the token was
        obtained on behalf of a user or an application identity, by
        omitting it in the latter case. We had extensive discussions
        following IETF105 and concluded that not enough people were
        interested in that scenario. I kept that discussion open for a
        long time.

      
- for privacy concerns. Those has been debated and
        your position failed to gather momentum.

      


      

      
Some of the recent discussions on sub didn’t pick
        up on the discussions above and didn’t bring new arguments that
        weren’t already debated. Nonetheless I did my best to provide
        context and pointer to the past discussions when answering the
        concerns. In other words, those discussions didn’t appear to
        change the consensus achieved on the matter. We have 3 last
        calls, I don’t think the chairs changed the status of the
        document lightly.

      


      

      


      

      


        

          
On Thu, May 14, 2020 at
            07:29 Denis <denis.ietf@free.fr> wrote:

          

          

            

              
The current version of this draft is
                    "draft-ietf-oauth-access-token-jwt-07" issued on
                    April the 27 th.

                    

                    This means that comments sent later on on the list
                    have not been incorporated in this draft. 

                    In particular, this one sent on April the 28 th:

                    

                    1) The title of this spec. is: 

                  
                
JSON Web Token
                      (JWT) Profile for OAuth 2.0 Access Tokens

                    

                 So, this spec. is supposed to be
                    targeted to OAuth 2.0.  

                    

                    However, the header at the top of the page omits to
                    mention it. 

                    

                    Currently, it is : 

                  
                
Internet-Draft      
                      OAuth Access Token JWT Profile           April
                      2020

                    

                It should rather be:

                  
                
Internet-Draft      
                      OAuth 2.0 Access Token JWT
                      Profile           April 2020

                    

                It has been acknowledged by Vittorio on
                    April, the 29 th:

                    

                    > The title of this spec.

                  

                    Fixed, thanks!

                  

              


                  

              
This means that the draft document
                    currently available on the IETF server is not
                    reflecting the agreed comments.

                    

                    Since then, I questioned myself how a client would
                    be able to request an access token that would be 

                    strictly compliant with this Profile. 

                    

                    For doing this exercise, I took a look at section 3
                    on pages 6 to 8. To summarize my findings:

                  
                
    
                  
  •  the request MAY include a
                        "resource" parameter. If the request does not
                        include a "resource" parameter, 
    
                        the authorization server MUST use in the "aud"
                        claim a default resource indicator.
    • 
                  
  •  the request MAY include "scope"
                        parameter. If a "scope" parameter is present in
                        the request, 
    
                        the authorization server SHOULD use it to infer
                        the value of the default resource indicator to
                        be used in the "aud" claim.
    • 
                

                 It seems to mean that if the request
                    includes no "resource" parameter and no "scope"
                    parameter, the access token will necessarily 

                    include the "sub" claim. 

                    

                    If in the request, there would be present a
                    parameter meaning "I want a token compliant with this
                      OAuth 2.0 profile", 

                    then there would be no problem, but this is not the
                    case.

              


                  

              
In the future, if additional
                      parameters are included in the request, will the
                      "sub" claim necessarily be present in the access
                      token ? 

                      If yes, this may be a privacy concern.

                    

              
 

                    On the list there have been requirements for not
                    making the "sub" parameter mandatory.

                    

                    This point needs to be addressed and solved one way
                    or another.

            

            

              


                    

                  

              
Denis

              

              


              

              

                
All,
                  


                  

                  
Based on the 3rd WGLC, we believe that we have
                    consensus to move this document forward.

                  
                  


                  

                  
We will be working on the shepherd write-up and
                    then submit the document to the IESG soon.

                  


                  

                  
Regards,

                  
 Rifaat & Hannes

                  


                  

                

                

                

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


              

              


              

            

          

        

      

    

    


    

  


--------------85D0D26396AFC0A13C52081C--


From nobody Thu May 14 09:29:35 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A058F3A0BBF for ; Thu, 14 May 2020 09:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.539
X-Spam-Level: 
X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZMQjkWc9qDY for ; Thu, 14 May 2020 09:29:29 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268083A0BB2 for ; Thu, 14 May 2020 09:29:27 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d81 with ME id egVQ2200T4FMSmm03gVRpL; Thu, 14 May 2020 18:29:26 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 14 May 2020 18:29:26 +0200
X-ME-IP: 86.238.65.197
To: Vittorio Bertocci , "oauth@ietf.org" 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> 
From: Denis 
Message-ID: 
Date: Thu, 14 May 2020 18:29:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4BC327CEBD24DA60E0E1F9A8"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 16:29:33 -0000

This is a multi-part message in MIME format.
--------------4BC327CEBD24DA60E0E1F9A8
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Vittorio,

I am referring to the email you sent on April the 29 th which is copied 
below.

1) You wrote:

    /> targeting of access tokens/

    Let me think about that a bit longer.

    I acknowledge that the decision of including an audience has the
    effect of letting the AS track when the client accesses a particular
    resource,
    but at the same time thats completely mainstream and very much by
    design in a very large number of cases. As such, I find the language
    you are suggesting to be potentially confusing, as it positions this
    as an exception vs a privacy protecting mainstream that is in fact
    not common,
    and ascribes to the client more latitude than I believe is
    legitimate to expect or grant.

    *Ill try to come up with concise language that clarifies to the
    reader that the current mechanism does allow AS tracking*.

Since the last draft has been published on the 27 th, you have not 
proposed any "concise language that clarifies to the reader
that the current mechanism does allow AS tracking".

2) You also wrote about the "sub" uniqueness:

    As long as an identifier identifies one resource only, it satisfies
    uniqueness. It doesnt have to be a singleton.

RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim using 
the following sentence:

    The subject value MUST either be scoped to be locally unique in the
    context of the issuer or be globally unique.

The text does NOT say that the subject value "MUST be scoped to be 
locally unique in the context of the *resource server*".
Changing the semantics of an already defined claim is not permitted. If 
you would like to have such a semantics available,
a new claim should be defined (and it would be very nice to have it !).

3) The text is the privacy considerations section states:

  Although the ability to correlate requests might be required by 
design in many scenarios, there are scenarios where the authorization
  server might want to prevent correlation to preserve the desired 
level of privacy.

In the real world, it is also clients or end-users which would like to 
prevent correlation to preserve their desired level of privacy.

A better sentence would be:

  Although the ability to correlate requests might be required by 
design in many scenarios, there are scenarios where the authorization
  server *or the client* might want to prevent correlation to preserve 
the desired level of privacy.

4) The text continues with:

  Authorization servers should choose how to assign "sub" values 
according to the level of privacy required by each
  situation. For instance: if a solution requires preventing 
tracking principal activities across multiple resource servers,
  the authorization server should ensure that JWT access tokens meant 
for different resource servers have distinct "sub"
  values that cannot be correlated in the event of resource servers 
collusion.

Authorization servers are not necessarily able to choose the level of 
privacy required by each situation. When there are different
situations for the same resource server, the scope is (unfortunately at 
the moment) the only way to select the "level of privacy that is required".

The example ("For instance:") is only an example that provides a vague 
recommendation for the ASs which is NOT conformant
with the semantics of the "sub" claim as defined in RFC 7519.

What should be discussed here are not "examples" or what an 
authorization server should do, but explanations about the implications
for the end-user or for the client for the various values that can be 
placed into the "sub" claim by an AS. The problem is wider that simply
a collusion between resource servers, but also with other servers that 
DO NOT participate in any OAuth exchange.

RFC 6973 (Privacy Considerations) states in section 7 : Guidelines

    This section provides guidance for document authors in the form of a
    questionnaire about a protocol being designed.
    The questionnaire may be useful at any point in the design process,
    particularly after document authors have developed
    a high-level protocol model as described in [RFC4101].

One of the questions is:

    f. *Correlation*. Does the protocol allow for correlation of
    identifiers ? Are there expected ways that information exposed
    by the protocol will be combined or *correlated with information
    obtained outside the protocol* ?

It is important to provide an answer to these two questions.

Hereafter is some text that is fully conformant with RFC 7519 which 
should be incorporated into the privacy considerations section
which explains the implications of the two (and only two) flavours of 
the "sub" claim.

    When the sub claim contains a locally unique identifier in the
    context of the issuer, this allows the tracking of principal activities
    across multiple resource servers.

    When the sub claim contains a globally unique identifier, this
    allows to correlate principal activities across multiple resource
    servers, while in addition, this globally unique identifier may also
    allow to correlate the principal activities on servers where
    no access has been performed by the principals to these servers but
    where the same globally unique identifiers are being used
    by these servers.

Denis

> Thanks Denis for the thorough commentary.
>
> /> The title of this spec./
>
> Fixed, thanks!
>
> /> The client MUST NOT inspect the content of the access token/
>
> This is really a sticky point. I really want to acknowledge your PoV 
> on this, but at the same time I found this to be one of the biggest 
> sources of issues in the use of JWT for access tokens hence I feel we 
> really need to give solid guidance here. Let me expand further on the 
> reasoning behind it, and perhaps we can get to language that satisfies 
> both PoVs.
>
> To me the key point is that clients should not write /code/ that 
> inspects access tokens. Taking a dependency on the ability to do so is 
> ignoring fundamental information about the architecture and 
> relationships between OAuth roles, and suggests an ability of the 
> client to understand the semantic of the content that cannot be 
> assumed in the general case. I expanded on the details in my former 
> reply to you on this topic, I would recommend referring to it. Clients 
> violating this simple principle has been one of the most common 
> sources of production issues I had to deal with in the past few years, 
> and one of the hardest to remediate given that clients are hard to 
> update and sometimes the things they relied on were irremediably lost. 
> This is why I am inclined to put in here strong language.
>
> That said: I have nothing against client developers examining a 
> network trace and drawing conclusions based on the content of what 
> they see. That doesnt create any hard dependencies and has no 
> implications in respect to changes in the solution behavior. However I 
> am not sure how to phrase that in the specification, given that 
> referring to the client inevitably refers to its code. I am open to 
> suggestions.
>
> > 3)
>
> I have a pretty hard time following the chain of reasoning in this 
> section. Let me attempt to tackle it to the best of my understanding.
>
> I think the key might be
>
> /> a client should be able to choose whether it wishes the sub claim 
> to contain [..]/
>
> I dont think that should be a choice left to the client. In business 
> systems, my experience is that the type of identifiers to be used 
> (when the IdP gives any choice at all) is established at resource 
> provisioning time. I am not aware of mechanisms thru which a client 
> signals the nature of the identifier to be used, nor that would be 
> fully feasible (the resource knows what it needs to perform its function).
>
> Furthermore:
>
> /> which has nothing to do with uniqueness since the value changes for 
> every generated token./
>
> Again, this is something that was touched on in my former reply to 
> your message. As long as an identifier identifies one resource only, 
> it satisfies uniqueness. It doesnt have to be a singleton.
>
> Finally, the scope is optional (for good reasons: 1^st party and non 
> delegation scenarios dont require it) hence it cannot be relied upon 
> for properties that should hold in every scenario.
>
> In summary: per the preceding thread on this topic, the consensus was 
> that varying the sub content was a satisfactory way of protecting 
> against correlation. I dont a gree that clients should have a 
> mechanism to request different sub flavors, as that decision should be 
> done out of band by the AS and RS; and the scope isnt always 
> available anyway.
>
> /> targeting of access tokens/
>
> Let me think about that a bit longer.
>
> I acknowledge that the decision of including an audience has the 
> effect of letting the AS track when the client accesses a particular 
> resource, but at the same time thats completely mainstream and very 
> much by design in a very large number of cases. As such, I find the 
> language you are suggesting to be potentially confusing, as it 
> positions this as an exception vs a privacy protecting mainstream that 
> is in fact not common, and ascribes to the client more latitude than I 
> believe is legitimate to expect or grant.
>
> Ill try to come up with concise language that clarifies to the reader 
> that the current mechanism does allow AS tracking.
>
> *From: *OAuth  on behalf of Denis 
> 
> *Date: *Wednesday, April 29, 2020 at 09:12
> *To: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> for OAuth 2.0 Access Tokens"
>
> You will find four comments numbered 1) to 4).
>
> *1) *The title of this spec. is:
>
> JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
>
> So, this spec. is supposed to be targeted to OAuth *2.0. *However, 
> the header at the top of the page omits to mention it.
>
> Currently, it is :
>
> Internet-Draft OAuth Access Token JWT Profile April 2020
>
> It should rather be:
>
> Internet-Draft OAuth *2.0* Access Token JWT Profile April 2020
>
> *2)* The following text is within section 6.
>
> The client MUST NOT inspect the content of
> the access token: the authorization server and the resource server
> might decide to change token format at any time (for example by
> switching from this profile to opaque tokens) hence any logic in the
> client relying on the ability to read the access token content would
> break without recourse.
> Nonetheless, authorization servers should
> not assume that clients will comply with the above.
>
> It is of a primary importance that clients MAY be able to inspect 
> tokens before transmitting them.
> The "MUST NOT" is not acceptable.
>
> The above text should be replaced with:
>
> Reading the access token content may be useful for the user to verify 
> that
> the access token content matches with its expectations. However,
> the authorization server and the resource server might decide to 
> change the
> token format at any time. Thus, the client should not expect to 
> always be
> in a position to read the access token content.
>
> The remaining of the text about this topic is fine.
>
>
> *3) *The next topic is about the sub claim.
>
> The text states:
>
> Although the ability to correlate requests might be required by
> design in many scenarios, there are scenarios where the authorization
> server might want to prevent correlation to preserve the desired
> level of privacy. Authorization servers should choose how to assign
> sub values according to the level of privacy required by each
> situation.
>
> I have a set of questions:
>
>  1. How can authorization servers choose how to assign sub values
>     according to the level of privacy required "by each situation" ?
>  2. How can authorization servers know the level of privacy required
>     "by each situation" ?
>  3. How can the users be informed of the level of privacy required "by
>     each situation" ?
>  4. How can the users *consent* with the level of privacy required "by
>     each situation" ?
>
> Currently, the request MUST include either a resource parameter or an 
> aud claim parameter, while it MAY include a scope parameter.
>
> The syntax of the scope parameter is a list of space-delimited, 
> case-sensitive strings (RFC 6749). It is thus subject to private 
> agreements
> between clients and Authorization Servers. Since the scope is being 
> returned, it is a primary importance that the returned scope matches
> with its expectations before transmitting the token to a Resource Server.
>
> In theory, a client should be able to choose whether it wishes the sub 
> claim to contain :
>
>   * a global unique identifier for all ASs ("globally unique"),
>   * a unique identifier for each AS ("locally unique in the context of
>     the issuer"),
>   * a different pseudonym for each RS, or
>   * a different pseudonym for each authorization token request.
>
> The only variable parameter that it can use for this purpose in the 
> token request is the scope parameter.
>
> RFC 7519 states is section 4.1.2:
>
> The subject value MUST either be scoped to be locally unique in the 
> context of the issuer
> or be globally unique.
>
> It is quite hard to recognize that the sub claim is able to carry a 
> different pseudonym for each RS, i.e. for case (c), or
> a different pseudonym for each authorization token request, i.e. for 
> case (d), which has nothing to do with uniqueness
> since the value changes for every generated token.
>
> This has implications about the following text:
>
> For instance: if a solution requires preventing tracking
> principal activities across multiple resource servers, the
> authorization server should ensure that JWT access tokens meant for
> different resource servers have distinct sub values that cannot be
> correlated in the event of resource servers collusion.
>
> Since it addresses case (c).
>
> and also about the following text:
>
> 4.b) Similarly: if a solution requires preventing a resource server from
> correlating the principals activity within the resource itself, the
> authorization server should assign different sub values for every JWT
> access token issued.
>
> Since it addresses case (d).
>
> This means that the current text placed in the privacy considerations 
> section was a good attempt to address the case,
> but that the text needs to be revised.
>
> Proposed text replacement for all the previously quoted sentences:
>
> According to RFC 7519 (4.1.2): The subject value MUST either be scoped 
> to be locally unique in the context of the issuer or be globally unique.
>
> When the sub claim contains a globally unique identifier, this allows 
> to correlate principal activities across multiple resource servers, 
> while in addition,
> this globally unique identifier may also allow to correlate the 
> principal activities on servers where no access has been performed by 
> the principals
> to these servers but where the same globally unique identifiers are 
> being used by these servers.
>
> When the sub claim contains a locally unique identifier in the context 
> of the issuer, this also allows the tracking of principal activities 
> across multiple resource servers.
>
> The scope request parameter is the only way to influence on the 
> content of the sub claim parameter. Its meaning is subject to a 
> private agreement
> between the client and the AS, which means that the use of the scope 
> parameter is the only way to choose between a locally unique identifier
> in the context of the issuer or a globally unique identifier.
>
> Since the scope parameter is being returned, it is a primary 
> importance that the returned scope matches with the expectations of 
> the client before transmitting
> the token to a Resource Server.
>
> However, there are other cases where the client would like to be able 
> to choose whether it wishes the sub claim to contain :
>  - a different pseudonym for each RS so that different resource 
> servers will be unable to correlate its activities, or
>  - a different pseudonym for each authorization token request, so 
> that the same resource server cannot correlate its activities 
> performed at different instant of time.
>
> Considering the semantics of the sub claim, these two cases cannot be 
> currently supported.
>
>
> *4) *The next topic is about the targeting of access tokens
>
> Text had been proposed before the last conference call. Then, the 
> topic has been presented at the very end of the last conference call, 
> but no text has been included
> in the next draft.
>
> Here is a revised text be included in the privacy considerations section:
>
> For security reasons, some clients may be willing to target their 
> access tokens but, for privacy reasons, may be unwilling to disclose 
> to Authorization Servers
> an identification of the Resource Servers they are going to access, so 
> that Authorization Servers will be unable to know which resources 
> servers are being accessed.
> The disclosure of the Resource Servers names allows the Authorization 
> Servers to list all the Resource Servers being access by all its users 
> and in addition to list pairs
> of (Principal, Resource Servers) which allow to trace all the users 
> accesses to Resource Servers performed through a given Authorization 
> Server. When a token is targeted,
> this profile does not contain provisions to address these two threats.
>
> Denis
>
>     Hi all,
>
>     This is a second working group last call for "JSON Web Token (JWT)
>     Profile for OAuth 2.0 Access Tokens".
>
>     Here is the document:
>
>     https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>     Please send your comments to the OAuth mailing list by April 29, 2020.
>
>     Regards,
>
>     Rifaat & Hannes
>
>
>
>     _______________________________________________
>
>     OAuth mailing list
>
>     OAuth@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/oauth
>


--------------4BC327CEBD24DA60E0E1F9A8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Vittorio,

    


    

    
I am referring to
        the email you sent on April the 29 th which is copied below.

    


      

    
1) You wrote:

    

      

        
> targeting of
              access tokens

        
Let me think about that
            a bit longer. 

        
I acknowledge that the
            decision of including an audience has the effect of letting
            the AS track when the client accesses a particular resource,
            

            but at the same time thats completely mainstream and very
            much by design in a very large number of cases. As such, I
            find the language 

            you are suggesting to be potentially confusing, as it
            positions this as an exception vs a privacy protecting
            mainstream that is in fact not common, 

            and ascribes to the client more latitude than I believe is
            legitimate to expect or grant.

            

          

        Ill try to come up with concise language
            that clarifies to the reader that the current mechanism does
            allow AS tracking.  

        

    

    
Since the last draft has been published
      on the 27 th, you have not proposed any "concise
        language that clarifies to the reader 

        that the current mechanism does allow AS tracking".

    


    

    
2) You also wrote about the "sub"
      uniqueness:

    

      
As long as an identifier identifies
        one resource only, it satisfies uniqueness. It doesnt have to
        be a singleton.

    

    
RFC 7519 defines in section 4.1.2 the
      semantics of the "sub" claim using the following sentence:

      
The subject value MUST either be scoped to be locally
        unique in the context of the issuer or be globally unique.

    

    
The text does NOT say that the subject
      value "MUST be scoped to be locally unique in the context of the resource
        server".

    

    
Changing the semantics of an already
      defined claim is not permitted. If you would like to have such a
      semantics available, 

      a new claim should be defined (and it would be very nice to have
      it !). 

    

    


    

    
3) The text is the privacy
      considerations section states:

    


    

    
 Although the ability to correlate
      requests might be required by design in many scenarios, there are
      scenarios where the authorization

       server might want to prevent correlation to preserve the
      desired level of privacy. 

    

    


    

    
In the real world, it is also clients
      or end-users which would like to prevent correlation to preserve
      their desired level of privacy.

    


    

    
A better sentence would be:

    

      


      

      
 Although the ability to correlate
        requests might be required by design in many scenarios, there
        are scenarios where the authorization

         server or the client might want to prevent
        correlation to preserve the desired level of privacy. 

      

      


      

    

    
4) The text continues with:

    


    

    
 Authorization servers should choose
      how to assign "sub" values according to the level of privacy
      required by each

       situation. For instance: if a solution requires preventing
      tracking principal activities across multiple resource servers, 

       the authorization server should ensure that JWT access tokens
      meant for different resource servers have distinct "sub" 

       values that cannot be correlated in the event of resource
      servers collusion. 

    

    


    

    
Authorization servers are not
      necessarily able to choose the level of privacy required by each
      situation. When there are different 

      situations for the same resource server, the scope is
      (unfortunately at the moment) the only way to select the "level of
      privacy that is required".

    


    

    
The example ("For instance:") is only
      an example that provides a vague recommendation for the ASs which
      is NOT conformant

      with the semantics of the "sub" claim as defined in RFC 7519.

    


    

    
What should be discussed here are not
      "examples" or what an authorization server should do, but
      explanations about the implications 

      for the end-user or for the client for the various values that can
      be placed into the "sub" claim by an AS. The problem is wider that
      simply 

      a collusion between resource servers, but also with other servers
      that DO NOT participate in any OAuth exchange. 

    

    


    

    
RFC 6973 (Privacy Considerations)
      states in section 7 : Guidelines

      
This section provides guidance for document authors in
        the form of a questionnaire about a protocol being designed. 

        The questionnaire may be useful at any point in the design
        process, particularly after document authors have developed 

        a high-level protocol model as described in [RFC4101].

      

      One of the questions is:

      
f. Correlation. Does the protocol allow for
        correlation of identifiers ? Are there expected ways that
        information exposed 

        by the protocol will be combined or correlated with
          information obtained outside the protocol ?

    

    
It is important to provide an answer to
      these two questions.

    


    

    
Hereafter is some text that is fully
      conformant with RFC 7519 which should be incorporated into the
      privacy considerations section 

      which explains the implications of the two (and only two) flavours
      of the "sub" claim.

    

      
When the sub claim contains a locally
        unique identifier in the context of the issuer, this allows the
        tracking of principal activities 

        across multiple resource servers.

      


      

      
When the sub claim contains a
        globally unique identifier, this allows to correlate principal
        activities across multiple resource 

        servers, while in addition, this globally unique identifier may
        also allow to correlate the principal activities on servers
        where 

        no access has been performed by the principals
        to these servers but where the same globally unique identifiers
        are being used 

        by these servers.

      

    

    
Denis

      

    

    

      
      
      
      

        
Thanks Denis for the thorough commentary.

        

        
> The title of this spec.

        
Fixed, thanks!

        

        
> The client MUST NOT inspect the
            content of the access token

        
This is really a sticky point. I really
          want to acknowledge your PoV on this, but at the same time I
          found this to be one of the biggest sources of issues in the
          use of JWT for access tokens hence I feel we really need to
          give solid guidance here. Let me expand further on the
          reasoning behind it, and perhaps we can get to language that
          satisfies both PoVs.

        
To me the key point is that clients should
          not write code that inspects access tokens. Taking a
          dependency on the ability to do so is ignoring fundamental
          information about the architecture and relationships between
          OAuth roles, and suggests an ability of the client to
          understand the semantic of the content that cannot be assumed
          in the general case. I expanded on the details in my former
          reply to you on this topic, I would recommend referring to it.
          Clients violating this simple principle has been one of the
          most common sources of production issues I had to deal with in
          the past few years, and one of the hardest to remediate given
          that clients are hard to update and sometimes the things they
          relied on were irremediably lost. This is why I am inclined to
          put in here strong language.

        
That said: I have nothing against client
          developers examining a network trace and drawing conclusions
          based on the content of what they see. That doesnt create any
          hard dependencies and has no implications in respect to
          changes in the solution behavior. However I am not sure how to
          phrase that in the specification, given that referring to the
          client inevitably refers to its code. I am open to
          suggestions.

        

        
> 3)

        
I have a pretty hard time following the
          chain of reasoning in this section. Let me attempt to tackle
          it to the best of my understanding.

        
I think the key might be 

        
> a client should be able to choose
            whether it wishes the sub claim to contain [..]

        
I dont think that should be a choice left
          to the client. In business systems, my experience is that the
          type of identifiers to be used (when the IdP gives any choice
          at all) is established at resource provisioning time. I am
          not aware of mechanisms thru which a client signals the nature
          of the identifier to be used, nor that would be fully feasible
          (the resource knows what it needs to perform its function).

        
Furthermore:

        
> which has nothing to do with
            uniqueness since the value changes for every generated
            token.

        
Again, this is something that was touched
          on in my former reply to your message. As long as an
          identifier identifies one resource only, it satisfies
          uniqueness. It doesnt have to be a singleton.
          

        
Finally, the scope is optional (for good
          reasons: 1st party and non delegation scenarios
          dont require it) hence it cannot be relied upon for
          properties that should hold in every scenario.

        
In summary: per the preceding thread on
          this topic, the consensus was that varying the sub content was
          a satisfactory way of protecting against correlation. I dont
          a gree that clients should have a mechanism to request
          different sub flavors, as that decision should be done out of
          band by the AS and RS; and the scope isnt always available
          anyway.

        

        
> targeting of access tokens

        
Let me think about that a bit longer. 

        
I acknowledge that the decision of
          including an audience has the effect of letting the AS track
          when the client accesses a particular resource, but at the
          same time thats completely mainstream and very much by design
          in a very large number of cases. As such, I find the language
          you are suggesting to be potentially confusing, as it
          positions this as an exception vs a privacy protecting
          mainstream that is in fact not common, and ascribes to the
          client more latitude than I believe is legitimate to expect or
          grant.

        
Ill try to come up with concise language
          that clarifies to the reader that the current mechanism does
          allow AS tracking. 

        

        

          
From: OAuth
              <oauth-bounces@ietf.org> on behalf of Denis
              <denis.ietf@free.fr>

              Date: Wednesday, April 29, 2020 at 09:12

              To: "oauth@ietf.org" <oauth@ietf.org>

              Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web
              Token (JWT) Profile for OAuth 2.0 Access Tokens"

        

        

          

        

        

          
You will find four comments numbered 1)
            to 4). 

        

        

          
1)
            The title of this spec. is:

            

            JSON Web
              Token (JWT) Profile for OAuth
              2.0 Access Tokens

            

            So, this spec. is supposed to be targeted to OAuth 2.0.
            However, the header at the top of the page omits to
            mention it.
            

            

            Currently, it is :

          
Internet-Draft
            OAuth Access Token JWT Profile April 2020

          
It
            should rather be:

          
Internet-Draft
            OAuth
            2.0 Access Token JWT Profile April 2020

            

            2) The following text is within section 6.

            

            The client MUST NOT inspect the content of

            the access token: the authorization server and the resource
            server

            might decide to change token format at any time (for example
            by

            switching from this profile to opaque tokens) hence any
            logic in the

            client relying on the ability to read the access token
            content would

            break without recourse.

            Nonetheless, authorization servers should

            not assume that clients will comply with the above.

          
It
            is of a primary importance that clients MAY be able to
            inspect tokens before transmitting them.

            The "MUST NOT" is not acceptable. 

          
The
            above text should be replaced with:

            

            Reading the access token content may be useful for the user
            to verify that 

            the access token content matches with its expectations.
            However, 

            the authorization server and the resource server might
            decide to change the 

            token format at any time. Thus, the client should not
            expect to always be 

            in a position to read the access token content.

            

            The remaining of the text about this topic is fine.

            

            

            3) The next topic is about the sub claim.

            

            The text states:

            

            Although
              the ability to correlate requests might be required by

              design in many scenarios, there are scenarios where the
              authorization

              server might want to prevent correlation to preserve the
              desired

              level of privacy. Authorization servers should choose how
              to assign

              sub values according to the level of privacy required by
              each

              situation.

            

            I have a set of questions: 

          
    
            
  1. 
              How can authorization servers choose how to assign sub
              values according to the level of privacy required "by each
              situation" ?
    2. 
            
  2. 
              How can authorization servers know the level of privacy
              required "by each situation" ?
              
    3. 
            
  3. 
              How can the users be informed of the level of privacy
              required "by each situation" ?
    4. 
            
  4. 
              How can the users consent with the level of
              privacy required "by each situation" ?
    5. 
          

          
Currently,
            the request MUST include either a resource parameter or an
            aud claim parameter, while it MAY include a scope parameter.

          
The
            syntax of the scope parameter is a list of space-delimited,
            case-sensitive strings (RFC 6749). It is thus subject to
            private agreements
            

            between clients and Authorization Servers. Since the scope
            is being returned, it is a primary importance that the
            returned scope matches
            

            with its expectations before transmitting the token to a
            Resource Server.

            

            In theory, a client should be able to choose whether it
            wishes the sub claim to contain :

          
    
            
  • 
              a global unique identifier for all ASs ("globally
              unique"),
    • 
            
  • 
              a unique identifier for each AS ("locally unique in the
              context of the issuer"),
    • 
            
  • 
              a different pseudonym for each RS, or 
    • 
            
  • 
              a different pseudonym for each authorization token
              request.
    • 
          

          
The
            only variable parameter that it can use for this purpose in
            the token request is the scope parameter.

            

            RFC 7519 states is section 4.1.2:

            

            The
              subject value MUST either be scoped to be locally unique
              in the context of the issuer
              

              or be globally unique.

            

            It is quite hard to recognize that the sub claim is able to
            carry a different pseudonym for each RS, i.e. for case (c),
            or
            

            a different pseudonym for each authorization token request,
            i.e. for case (d), which has nothing to do with uniqueness
            

            since the value changes for every generated token.

            

            This has implications about the following text:

            

            For
              instance: if a solution requires preventing tracking

              principal activities across multiple resource servers, the

              authorization server should ensure that JWT access tokens
              meant for

              different resource servers have distinct sub values that
              cannot be

              correlated in the event of resource servers collusion.

              

            Since it addresses case (c).

            

            and also about the following text:

            

            4.b)
              Similarly: if a solution requires preventing a resource
              server from
              

              correlating the principals activity within the resource
              itself, the 

              authorization server should assign different sub values
              for every JWT 

              access token issued.

            

            Since it addresses case (d).

            

            This means that the current text placed in the privacy
            considerations section was a good attempt to address the
            case,
            

            but that the text needs to be revised.

            

            Proposed text replacement for all the previously quoted
            sentences:

            

            According to RFC 7519 (4.1.2): The subject value MUST either
            be scoped to be locally unique in the context of the issuer
            or be globally unique.

            

            When the sub claim contains a globally unique identifier,
            this allows to correlate principal activities across
            multiple resource servers, while in addition,
            

            this globally unique identifier may also allow to correlate
            the principal activities on servers where no access has been
            performed by the principals
            

            to these servers but where the same globally unique
            identifiers are being used by these servers.
            

            

            When the sub claim contains a locally unique identifier in
            the context of the issuer, this also allows the tracking of
            principal activities across multiple resource servers.

            

            The scope request parameter is the only way to influence on
            the content of the sub claim parameter. Its meaning is
            subject to a private agreement
            

            between the client and the AS, which means that the use of
            the scope parameter is the only way to choose between a
            locally unique identifier
            

            in the context of the issuer or a globally unique
            identifier.

            

            Since the scope parameter is being returned, it is a primary
            importance that the returned scope matches with the
            expectations of the client before transmitting
            

            the token to a Resource Server.

            

            However, there are other cases where the client would like
            to be able to choose whether it wishes the sub claim to
            contain :
            

             - a different pseudonym for each RS so that different
            resource servers will be unable to correlate its activities,
            or

             - a different pseudonym for each authorization token
            request, so that the same resource server cannot correlate
            its activities performed at different instant of time.
            

            

            Considering the semantics of the sub claim, these two cases
            cannot be currently supported.

            

            

            4) The next topic is about the targeting of access
            tokens

          
Text
            had been proposed before the last conference call. Then, the
            topic has been presented at the very end of the last
            conference call, but no text has been included
            

            in the next draft. 

          
Here
            is a revised text be included in the privacy considerations
            section:

          
For
            security reasons, some clients may be willing to target
            their access tokens but, for privacy reasons, may be
            unwilling to disclose to Authorization Servers
            

            an identification of the Resource Servers they are going to
            access, so that Authorization Servers will be unable to know
            which resources servers are being accessed.
            

            The disclosure of the Resource Servers names allows the
            Authorization Servers to list all the Resource Servers being
            access by all its users and in addition to list pairs
            

            of (Principal, Resource Servers) which allow to trace all
            the users accesses to Resource Servers performed through a
            given Authorization Server. When a token is targeted,
            

            this profile does not contain provisions to address these
            two threats.

            

            Denis

        

        

          

            
Hi all,

            

            
This is a
              second working group last call for "JSON Web Token (JWT)
              Profile for OAuth 2.0 Access Tokens".

            

            
Here is the
              document:

            
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

            

            
Please send
              your comments to the OAuth mailing list by April 29, 2020.

            

            
Regards,

            
Rifaat &
              Hannes

            

          

          


            

            

          
_______________________________________________

          
OAuth mailing list

          
OAuth@ietf.org

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

        

        

      

    

    


    

  


--------------4BC327CEBD24DA60E0E1F9A8--


From nobody Thu May 14 11:02:46 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ACF3A073E for ; Thu, 14 May 2020 11:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.062
X-Spam-Level: 
X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LONGWORDS=2.035, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXnY6uHpO9Ns for ; Thu, 14 May 2020 11:02:41 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F7B3A076E for ; Thu, 14 May 2020 11:02:41 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id z72so24376359wmc.2 for ; Thu, 14 May 2020 11:02:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hpcNWv361WWX4+/MSPzrEv9pkSRU+4d1y/V0WtM/pBc=; b=kiXywkntIZx/+kOVV+y4YLiX+PkbJSL12KSSApi/SEBRZ6LJ92+UICNB+tRQisKr9D qizFrHXITvGtvKJ4msMDX4YQ5cgu5NGkWQo47J0vn+JdEbDIirIdFt63mle78cd26eBs 7ghcRO6FZCTNf01ENPqPg7gma5J1LcOxW3S0qWJcm5g+shtlhHOQEpA5Lms0OSZqLb0a ns58HdpmGAJfcMgqlAO47nkigV6UZXaLVsw0tX3XYt3U7f4yuv8Zr58KhqY8YnbrSVop 5j8XMTf56l3PQUruYwaVcvueVk6j8tB4pr99+I16BV605Ybaomv9HkqJ+vtxPk62uluP fUkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hpcNWv361WWX4+/MSPzrEv9pkSRU+4d1y/V0WtM/pBc=; b=SA9II/BAavQE0VRYsozUahHb2H8VpmdMbVyl7EA5Dnma/QBA1qYnworGjnRf4IKVLw qxAObdDNurLT+ZYG5ywlt4dI156mCsDjABGxL6htCCEZg62ZPnyUlndiyx3qfuJbGu9B m7fjRwh3VzR5DGqn2Fb1RwZzdcaDT1owEhTTTjdmyWUG2j8JlVhCjoRQ9Jj052w5lQ9P IbF53hTCmR7nL+lX4GlR5pWo1y+NQxuK6PZ48YLkSaCga0TI1Xg350395xob/flF6fhQ 581YZawhPNxMPPGvVHxOSDA3oSzlvdqPwsqHl1js99GbWJfD7F5RV5PrziQE98/REoRR I8Cw==
X-Gm-Message-State: AOAM531pKtDxlEfycoJy/4wGgI9JfF6xT1amPY4BkTqGQqon16xFyIEM Vg394zS2JD6QyzLT0Yic4BR/MqM2DBXWoXu86LI=
X-Google-Smtp-Source: ABdhPJx204f3CY03jADVIv06hPjHWERLKZerQWzv5EiaS/xjYKWRkoGKDymk1hjNQikl7ahETnbTpkJ7zP+s4MWbl2I=
X-Received: by 2002:a05:600c:231a:: with SMTP id 26mr9559189wmo.59.1589479359416;  Thu, 14 May 2020 11:02:39 -0700 (PDT)
MIME-Version: 1.0
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Thu, 14 May 2020 14:02:30 -0400
Message-ID: 
To: Denis 
Cc: Vittorio Bertocci , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000988c6b05a59f805a"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 18:02:45 -0000

--000000000000988c6b05a59f805a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Denis,

You are rehashing the same issues that you have already discussed on the
mailing list multiple times,
You could not get the WG to agree with your points, because the WG
believe that this issue is outside the scope of this document.

The best the chairs can do at this stage is to capture your point in the
shepherd write-up to the IESG.
We think this document has the support of the WG and is ready to
move forward.

Regards,
 Rifaat


On Thu, May 14, 2020 at 12:29 PM Denis  wrote:

> Hi Vittorio,
>
> I am referring to the email you sent on April the 29 th which is copied
> below.
>
> 1) You wrote:
>
> *> targeting of access tokens*
>
> Let me think about that a bit longer.
>
> I acknowledge that the decision of including an audience has the effect o=
f
> letting the AS track when the client accesses a particular resource,
> but at the same time that=E2=80=99s completely mainstream and very much b=
y design
> in a very large number of cases. As such, I find the language
> you are suggesting to be potentially confusing, as it positions this as a=
n
> exception vs a privacy protecting mainstream that is in fact not common,
> and ascribes to the client more latitude than I believe is legitimate to
> expect or grant.
>
> *I=E2=80=99ll try to come up with concise language that clarifies to the =
reader
> that the current mechanism does allow AS tracking*.
>
> Since the last draft has been published on the 27 th, you have not
> proposed any "concise language that clarifies to the reader
> that the current mechanism does allow AS tracking".
>
> 2) You also wrote about the "sub" uniqueness:
>
> As long as an identifier identifies one resource only, it satisfies
> uniqueness. It doesn=E2=80=99t have to be a singleton.
>
> RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim using
> the following sentence:
>
> The subject value MUST either be scoped to be locally unique in the
> context of the issuer or be globally unique.
>
> The text does NOT say that the subject value "MUST be scoped to be locall=
y
> unique in the context of the *resource server*".
> Changing the semantics of an already defined claim is not permitted. If
> you would like to have such a semantics available,
> a new claim should be defined (and it would be very nice to have it !).
>
> 3) The text is the privacy considerations section states:
>
>    Although the ability to correlate requests might be required by design
> in many scenarios, there are scenarios where the authorization
>    server might want to prevent correlation to preserve the desired level
> of privacy.
>
> In the real world, it is also clients or end-users which would like to
> prevent correlation to preserve their desired level of privacy.
>
> A better sentence would be:
>
>    Although the ability to correlate requests might be required by design
> in many scenarios, there are scenarios where the authorization
>    server *or the client* might want to prevent correlation to preserve
> the desired level of privacy.
>
> 4) The text continues with:
>
>    Authorization servers should choose how to assign "sub" values
> according to the level of privacy required by each
>    situation.  For instance: if a solution requires preventing tracking
> principal activities across multiple resource servers,
>    the  authorization server should ensure that JWT access tokens meant
> for different resource servers have distinct "sub"
>    values that cannot be correlated in the event of resource servers
> collusion.
>
> Authorization servers are not necessarily able to choose the level of
> privacy required by each situation. When there are different
> situations for the same resource server, the scope is (unfortunately at
> the moment) the only way to select the "level of privacy that is required=
".
>
> The example ("For instance:") is only an example that provides a vague
> recommendation for the ASs which is NOT conformant
> with the semantics of the "sub" claim as defined in RFC 7519.
>
> What should be discussed here are not "examples" or what an authorization
> server should do, but explanations about the implications
> for the end-user or for the client for the various values that can be
> placed into the "sub" claim by an AS. The problem is wider that simply
> a collusion between resource servers, but also with other servers that DO
> NOT participate in any OAuth exchange.
>
> RFC 6973 (Privacy Considerations) states in section 7 : Guidelines
>
> This section provides guidance for document authors in the form of a
> questionnaire about a protocol being designed.
> The questionnaire may be useful at any point in the design process,
> particularly after document authors have developed
> a high-level protocol model as described in [RFC4101].
>
> One of the questions is:
>
> f.  *Correlation*.  Does the protocol allow for correlation of
> identifiers ?  Are there expected ways that information exposed
> by the protocol will be combined or *correlated with information obtained
> outside the protocol* ?
>
> It is important to provide an answer to these two questions.
>
> Hereafter is some text that is fully conformant with RFC 7519 which shoul=
d
> be incorporated into the privacy considerations section
> which explains the implications of the two (and only two) flavours of the
> "sub" claim.
>
> When the sub claim contains a locally unique identifier in the context of
> the issuer, this allows the tracking of principal activities
> across multiple resource servers.
>
> When the sub claim contains a globally unique identifier, this allows to
> correlate principal activities across multiple resource
> servers, while in addition, this globally unique identifier may also allo=
w
> to correlate the principal activities on servers where
> no access has been performed by the principals to these servers but where
> the same globally unique identifiers are being used
> by these servers.
>
> Denis
>
> Thanks Denis for the thorough commentary.
>
>
>
> *> The title of this spec.*
>
> Fixed, thanks!
>
>
>
> *> The client MUST NOT inspect the content of the access token*
>
> This is really a sticky point. I really want to acknowledge your PoV on
> this, but at the same time I found this to be one of the biggest sources =
of
> issues in the use of JWT for access tokens hence I feel we really need to
> give solid guidance here. Let me expand further on the reasoning behind i=
t,
> and perhaps we can get to language that satisfies both PoVs.
>
> To me the key point is that clients should not write *code* that inspects
> access tokens. Taking a dependency on the ability to do so is ignoring
> fundamental information about the architecture and relationships between
> OAuth roles, and suggests an ability of the client to understand the
> semantic of the content that cannot be assumed in the general case. I
> expanded on the details in my former reply to you on this topic, I would
> recommend referring to it. Clients violating this simple principle has be=
en
> one of the most common sources of production issues I had to deal with in
> the past few years, and one of the hardest to remediate given that client=
s
> are hard to update and sometimes the things they relied on were
> irremediably lost. This is why I am inclined to put in here strong langua=
ge.
>
> That said: I have nothing against client developers examining a network
> trace and drawing conclusions based on the content of what they see. That
> doesn=E2=80=99t create any hard dependencies and has no implications in r=
espect to
> changes in the solution behavior. However I am not sure how to phrase tha=
t
> in the specification, given that referring to the client inevitably refer=
s
> to its code. I am open to suggestions.
>
>
>
> >  3)=E2=80=A6
>
> I have a pretty hard time following the chain of reasoning in this
> section. Let me attempt to tackle it to the best of my understanding.
>
> I think the key might be
>
> *> a client should be able to choose whether it wishes the sub claim to
> contain [..]*
>
> I don=E2=80=99t think that should be a choice left to the client. In busi=
ness
> systems, my experience is that the type of identifiers to be used (when t=
he
> IdP gives any choice at all)  is established at resource provisioning tim=
e.
> I am not aware of mechanisms thru which a client signals the nature of th=
e
> identifier to be used, nor that would be fully feasible (the resource kno=
ws
> what it needs to perform its function).
>
> Furthermore:
>
> *> which has nothing to do with uniqueness since the value changes for
> every generated token.*
>
> Again, this is something that was touched on in my former reply to your
> message. As long as an identifier identifies one resource only, it
> satisfies uniqueness. It doesn=E2=80=99t have to be a singleton.
>
> Finally, the scope is optional (for good reasons: 1st party and non
> delegation scenarios don=E2=80=99t require it) hence it cannot be relied =
upon for
> properties that should hold in every scenario.
>
> In summary: per the preceding thread on this topic, the consensus was tha=
t
> varying the sub content was a satisfactory way of protecting against
> correlation. I don=E2=80=99t a gree that clients should have a mechanism =
to request
> different sub flavors, as that decision should be done out of band by the
> AS and RS; and the scope isn=E2=80=99t always available anyway.
>
> *> targeting of access tokens*
>
> Let me think about that a bit longer.
>
> I acknowledge that the decision of including an audience has the effect o=
f
> letting the AS track when the client accesses a particular resource, but =
at
> the same time that=E2=80=99s completely mainstream and very much by desig=
n in a
> very large number of cases. As such, I find the language you are suggesti=
ng
> to be potentially confusing, as it positions this as an exception vs a
> privacy protecting mainstream that is in fact not common, and ascribes to
> the client more latitude than I believe is legitimate to expect or grant.
>
> I=E2=80=99ll try to come up with concise language that clarifies to the r=
eader
> that the current mechanism does allow AS tracking.
>
>
>
> *From: *OAuth   on behalf
> of Denis  
> *Date: *Wednesday, April 29, 2020 at 09:12
> *To: *"oauth@ietf.org"   
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> You will find four comments numbered 1) to 4).
>
> *1) *The title of this spec. is:
>
> JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
>
> So, this spec. is supposed to be targeted to OAuth *2.0. * However, the
> header at the top of the page omits to mention it.
>
> Currently, it is :
>
> Internet-Draft       OAuth Access Token JWT Profile           April 2020
>
> It should rather be:
>
> Internet-Draft       OAuth *2.0* Access Token JWT Profile           April
> 2020
>
> *2)* The following text is within section 6.
>
> The client MUST NOT inspect the content of
> the access token: the authorization server and the resource server
> might decide to change token format at any time (for example by
> switching from this profile to opaque tokens) hence any logic in the
> client relying on the ability to read the access token content would
> break without recourse.
> Nonetheless, authorization servers should
> not assume that clients will comply with the above.
>
> It is of a primary importance that clients MAY be able to inspect tokens
> before transmitting them.
> The "MUST NOT" is not acceptable.
>
> The above text should be replaced with:
>
> Reading the access token content may be useful for the user to verify tha=
t
> the access token content matches with its expectations.  However,
> the authorization server and the resource server might decide to change
> the
> token format at any time.  Thus, the client should not expect to always b=
e
> in a position to read the access token content.
>
> The remaining of the text about this topic is fine.
>
>
> *3) *The next topic is about the sub claim.
>
> The text states:
>
> Although the ability to correlate requests might be required by
> design in many scenarios, there are scenarios where the authorization
> server might want to prevent correlation to preserve the desired
> level of privacy. Authorization servers should choose how to assign
> sub values according to the level of privacy required by each
> situation.
>
> I have a set of questions:
>
>    1. How can authorization servers choose how to assign sub values
>    according to the level of privacy required "by each situation" ?
>    2. How can authorization servers know the level of privacy required
>    "by each situation" ?
>    3. How can the users be informed of the level of privacy required "by
>    each situation" ?
>    4. How can the users *consent* with the level of privacy required "by
>    each situation" ?
>
> Currently, the request MUST include either a resource parameter or an aud
> claim parameter, while it MAY include a scope parameter.
>
> The syntax of the scope parameter is a list of space-delimited,
> case-sensitive strings (RFC 6749). It is thus subject to private agreemen=
ts
> between clients and Authorization Servers. Since the scope is being
> returned, it is a primary importance that the returned scope matches
> with its expectations before transmitting the token to a Resource Server.
>
> In theory, a client should be able to choose whether it wishes the sub
> claim to contain :
>
>    - a global unique identifier for all ASs ("globally unique"),
>    - a unique identifier for each AS ("locally unique in the context of
>    the issuer"),
>    - a different pseudonym for each RS, or
>    - a different pseudonym for each authorization token request.
>
> The only variable parameter that it can use for this purpose in the token
> request is the scope parameter.
>
> RFC 7519 states is section 4.1.2:
>
> The subject value MUST either be scoped to be locally unique in the
> context of the issuer
> or be globally unique.
>
> It is quite hard to recognize that the sub claim is able to carry a
> different pseudonym for each RS, i.e. for case (c), or
> a different pseudonym for each authorization token request, i.e. for case
> (d), which has nothing to do with uniqueness
> since the value changes for every generated token.
>
> This has implications about the following text:
>
> For instance: if a solution requires preventing tracking
> principal activities across multiple resource servers, the
> authorization server should ensure that JWT access tokens meant for
> different resource servers have distinct sub values that cannot be
> correlated in the event of resource servers collusion.
>
> Since it addresses case (c).
>
> and also about the following text:
>
> 4.b) Similarly: if a solution requires preventing a resource server from
> correlating the principal=E2=80=99s activity within the resource itself, =
the
> authorization server should assign different sub values for every JWT
> access token issued.
>
> Since it addresses case (d).
>
> This means that the current text placed in the privacy considerations
> section was a good attempt to address the case,
> but that the text needs to be revised.
>
> Proposed text replacement for all the previously quoted sentences:
>
> According to RFC 7519 (4.1.2): The subject value MUST either be scoped to
> be locally unique in the context of the issuer or be globally unique.
>
> When the sub claim contains a globally unique identifier, this allows to
> correlate principal activities across multiple resource servers, while in
> addition,
> this globally unique identifier may also allow to correlate the principal
> activities on servers where no access has been performed by the principal=
s
> to these servers but where the same globally unique identifiers are being
> used by these servers.
>
> When the sub claim contains a locally unique identifier in the context of
> the issuer, this also allows the tracking of principal activities across
> multiple resource servers.
>
> The scope request parameter is the only way to influence on the content o=
f
> the sub claim parameter. Its meaning is subject to a private agreement
> between the client and the AS, which means that the use of the scope
> parameter is the only way to choose between a locally unique identifier
> in the context of the issuer or a globally unique identifier.
>
> Since the scope parameter is being returned, it is a primary importance
> that the returned scope matches with the expectations of the client befor=
e
> transmitting
> the token to a Resource Server.
>
> However, there are other cases where the client would like to be able to
> choose whether it wishes the sub claim to contain :
>     - a different pseudonym for each RS so that different resource server=
s
> will be unable to correlate its activities, or
>     - a different pseudonym for each authorization token request, so that
> the same resource server cannot correlate its activities performed at
> different instant of time.
>
> Considering the semantics of the sub claim, these two cases cannot be
> currently supported.
>
>
> *4) *The next topic is about the targeting of access tokens
>
> Text had been proposed before the last conference call. Then, the topic
> has been presented at the very end of the last conference call, but no te=
xt
> has been included
> in the next draft.
>
> Here is a revised text be included in the privacy considerations section:
>
> For security reasons, some clients may be willing to target their access
> tokens but, for privacy reasons, may be unwilling to disclose to
> Authorization Servers
> an identification of the Resource Servers they are going to access, so
> that Authorization Servers will be unable to know which resources servers
> are being accessed.
> The disclosure of the Resource Servers names allows the Authorization
> Servers to list all the Resource Servers being access by all its users an=
d
> in addition to list pairs
> of (Principal, Resource Servers) which allow to trace all the users
> accesses to Resource Servers performed through a given Authorization
> Server. When a token is targeted,
> this profile does not contain provisions to address these two threats.
>
> Denis
>
> Hi all,
>
>
>
> This is a second working group last call for "JSON Web Token (JWT) Profil=
e
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>
>
> Please send your comments to the OAuth mailing list by April 29, 2020.
>
>
>
> Regards,
>
>  Rifaat & 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
>

--000000000000988c6b05a59f805a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Denis,

You are rehashing the same issue=
s that you have already discussed on the mailing list multiple times,
=

You could not get the WG to agree with your points, because the WG bel=
ieve=C2=A0that this issue is outside the scope of this document.
=

The best the chairs can do at this stage is to capture your =
point in the shepherd write-up to the IESG.
We think this documen=
t has the support of the WG and is ready to move=C2=A0forward.
Regards,
=C2=A0Rifaat


=

On Thu, Ma=
y 14, 2020 at 12:29 PM Denis <deni=
s.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Vittorio,

    


    

    
I am referring to
        the email you sent on April the 29 th which is copied below.=


    


      

    
1) You wrote:

    

      

        
> targeting of
              access tokens

        
Let me think about that
            a bit longer. 

        
I acknowledge that the
            decision of including an audience has the effect of letting
            the AS track when the client accesses a particular resource,
            

            but at the same time that=E2=80=99s completely mainstream and v=
ery
            much by design in a very large number of cases. As such, I
            find the language 

            you are suggesting to be potentially confusing, as it
            positions this as an exception vs a privacy protecting
            mainstream that is in fact not common, 

            and ascribes to the client more latitude than I believe is
            legitimate to expect or grant.

            

          

        I=E2=80=99ll try to come up with concise la=
nguage
            that clarifies to the reader that the current mechanism does
            allow AS tracking. =C2=A0 

        

    

    
Since the last draft has been published
      on the 27 th, you have not proposed any "concise
        language that clarifies to the reader 

        that the current mechanism does allow AS tracking".
    


    

    
2) You also wrote about the "sub"
      uniqueness:

    

      
As long as an identifier identifies
        one resource only, it satisfies uniqueness. It doesn=E2=80=99t have=
 to
        be a singleton.

    

    
RFC 7519 defines in section 4.1.2 the
      semantics of the "sub" claim using the following sentence:<=
br>
      
The subject value MUST either be scoped to be locally
        unique in the context of the issuer or be globally unique.
    

    
The text does NOT say that the subject
      value "MUST be scoped to be locally unique in the context of the=
 resource
        server".

    

    
Changing the semantics of an already
      defined claim is not permitted. If you would like to have such a
      semantics available, 

      a new claim should be defined (and it would be very nice to have
      it !). 

    

    


    

    
3) The text is the privacy
      considerations section states:

    


    

    
=C2=A0=C2=A0 Although the ability to correlate
      requests might be required by design in many scenarios, there are
      scenarios where the authorization

      =C2=A0=C2=A0 server might want to prevent correlation to preserve the
      desired level of privacy. 

    

    


    

    
In the real world, it is also clients
      or end-users which would like to prevent correlation to preserve
      their desired level of privacy.

    


    

    
A better sentence would be:

    

      


      

      
=C2=A0=C2=A0 Although the ability to correlate
        requests might be required by design in many scenarios, there
        are scenarios where the authorization

        =C2=A0=C2=A0 server or the client might want to prevent
        correlation to preserve the desired level of privacy. 

      

      


      

    

    
4) The text continues with:

    


    

    
=C2=A0=C2=A0 Authorization servers should choose
      how to assign "sub" values according to the level of privac=
y
      required by each

      =C2=A0=C2=A0 situation.=C2=A0 For instance: if a solution requires pr=
eventing
      tracking=C2=A0 principal activities across multiple resource servers,=
 

      =C2=A0=C2=A0 the=C2=A0 authorization server should ensure that JWT ac=
cess tokens
      meant for different resource servers have distinct "sub" 
      =C2=A0=C2=A0 values that cannot be correlated in the event of resourc=
e
      servers collusion.=C2=A0 

    

    


    

    
Authorization servers are not
      necessarily able to choose the level of privacy required by each
      situation. When there are different 

      situations for the same resource server, the scope is
      (unfortunately at the moment) the only way to select the "level =
of
      privacy that is required".

    


    

    
The example ("For instance:") is only
      an example that provides a vague recommendation for the ASs which
      is NOT conformant

      with the semantics of the "sub" claim as defined in RFC 751=
9.

    


    

    
What should be discussed here are not
      "examples" or what an authorization server should do, but
      explanations about the implications 

      for the end-user or for the client for the various values that can
      be placed into the "sub" claim by an AS. The problem is wid=
er that
      simply 

      a collusion between resource servers, but also with other servers
      that DO NOT participate in any OAuth exchange. 

    

    


    

    
RFC 6973 (Privacy Considerations)
      states in section 7 : Guidelines

      
This section provides guidance for document authors in
        the form of a questionnaire about a protocol being designed.=C2=A0 =


        The questionnaire may be useful at any point in the design
        process, particularly after document authors have developed 

        a high-level protocol model as described in [RFC4101].

      

      One of the questions is:

      
f.=C2=A0 Correlation.=C2=A0 Does the protocol allo=
w for
        correlation of identifiers ?=C2=A0 Are there expected ways that
        information exposed 

        by the protocol will be combined or correlated with
          information obtained outside the protocol ?

    

    
It is important to provide an answer to
      these two questions.

    


    

    
Hereafter is some text that is fully
      conformant with RFC 7519 which should be incorporated into the
      privacy considerations section 

      which explains the implications of the two (and only two) flavours
      of the "sub" claim.

    

      
When the sub claim contains a locally
        unique identifier in the context of the issuer, this allows the
        tracking of principal activities 

        across multiple resource servers.

      


      

      
When the sub claim contains a
        globally unique identifier, this allows to correlate principal
        activities across multiple resource 

        servers, while in addition, this globally unique identifier may
        also allow to correlate the principal activities on servers
        where 

        no access has been performed by the principals
        to these servers but where the same globally unique identifiers
        are being used 

        by these servers.

      

    

    
Denis

      

    

    

     =20
     =20
     =20
      

        
Thanks Denis for the thorough commentary.=


        
=C2=A0

        
> The title of this spec.

        
Fixed, thanks!

        
=C2=A0

        
> The client MUST NOT inspect the
            content of the access token

        
This is really a sticky point. I really
          want to acknowledge your PoV on this, but at the same time I
          found this to be one of the biggest sources of issues in the
          use of JWT for access tokens hence I feel we really need to
          give solid guidance here. Let me expand further on the
          reasoning behind it, and perhaps we can get to language that
          satisfies both PoVs.

        
To me the key point is that clients should
          not write code that inspects access tokens. Taking a
          dependency on the ability to do so is ignoring fundamental
          information about the architecture and relationships between
          OAuth roles, and suggests an ability of the client to
          understand the semantic of the content that cannot be assumed
          in the general case. I expanded on the details in my former
          reply to you on this topic, I would recommend referring to it.
          Clients violating this simple principle has been one of the
          most common sources of production issues I had to deal with in
          the past few years, and one of the hardest to remediate given
          that clients are hard to update and sometimes the things they
          relied on were irremediably lost. This is why I am inclined to
          put in here strong language.

        
That said: I have nothing against client
          developers examining a network trace and drawing conclusions
          based on the content of what they see. That doesn=E2=80=99t creat=
e any
          hard dependencies and has no implications in respect to
          changes in the solution behavior. However I am not sure how to
          phrase that in the specification, given that referring to the
          client inevitably refers to its code. I am open to
          suggestions.

        
=C2=A0

        
> =C2=A03)=E2=80=A6

        
I have a pretty hard time following the
          chain of reasoning in this section. Let me attempt to tackle
          it to the best of my understanding.

        
I think the key might be =C2=A0=C2=A0=


        
> a client should be able to choose
            whether it wishes the sub claim to contain [..]

        
I don=E2=80=99t think that should be a choic=
e left
          to the client. In business systems, my experience is that the
          type of identifiers to be used (when the IdP gives any choice
          at all) =C2=A0is established at resource provisioning time. I am
          not aware of mechanisms thru which a client signals the nature
          of the identifier to be used, nor that would be fully feasible
          (the resource knows what it needs to perform its function).

        
Furthermore:

        
> which has nothing to do with
            uniqueness since the value changes for every generated
            token.

        
Again, this is something that was touched
          on in my former reply to your message. As long as an
          identifier identifies one resource only, it satisfies
          uniqueness. It doesn=E2=80=99t have to be a singleton.
          

        
Finally, the scope is optional (for good
          reasons: 1st party and non delegation scenarios
          don=E2=80=99t require it) hence it cannot be relied upon for
          properties that should hold in every scenario.

        
In summary: per the preceding thread on
          this topic, the consensus was that varying the sub content was
          a satisfactory way of protecting against correlation. I don=E2=80=
=99t
          a gree that clients should have a mechanism to request
          different sub flavors, as that decision should be done out of
          band by the AS and RS; and the scope isn=E2=80=99t always availab=
le
          anyway.

        

        
> targeting of access tokens=


        
Let me think about that a bit longer. 

        
I acknowledge that the decision of
          including an audience has the effect of letting the AS track
          when the client accesses a particular resource, but at the
          same time that=E2=80=99s completely mainstream and very much by d=
esign
          in a very large number of cases. As such, I find the language
          you are suggesting to be potentially confusing, as it
          positions this as an exception vs a privacy protecting
          mainstream that is in fact not common, and ascribes to the
          client more latitude than I believe is legitimate to expect or
          grant.

        
I=E2=80=99ll try to come up with concise lan=
guage
          that clarifies to the reader that the current mechanism does
          allow AS tracking. =C2=A0=C2=A0

        
=C2=A0

        

          
From: OAuth
              &=
lt;oauth-bounces@ietf.org> on behalf of Denis
              <d=
enis.ietf@free.fr>

              Date: Wednesday, April 29, 2020 at 09:12

              To: "oauth@ietf.org" <oauth@ietf.org>

              Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web
              Token (JWT) Profile for OAuth 2.0 Access Tokens"<=
u>

        

        

          
=C2=A0

        

        

          
You will find four comments numbered 1)
            to 4). 

        

        

          
1)
            The title of this spec. is:

            

            JSON Web
              Token (JWT) Profile for OAuth
              2.0 Access Tokens

            

            So, this spec. is supposed to be targeted to OAuth 2.0.
            =C2=A0However, the header at the top of the page omits to
            mention it.
            

            

            Currently, it is :=C2=A0

          
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
            OAuth Access Token JWT Profile=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 April 2020

          
It
            should rather be:

          
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
            OAuth
            2.0 Access Token JWT Profile=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 April 2020

            

            2) The following text is within section 6.

            

            The client MUST NOT inspect the content of

            the access token: the authorization server and the resource
            server

            might decide to change token format at any time (for example
            by

            switching from this profile to opaque tokens) hence any
            logic in the

            client relying on the ability to read the access token
            content would

            break without recourse.

            Nonetheless, authorization servers should

            not assume that clients will comply with the above.

          
It
            is of a primary importance that clients MAY be able to
            inspect tokens before transmitting them.

            The "MUST NOT" is not acceptable. 

          
The
            above text should be replaced with:

            

            Reading the access token content may be useful for the user
            to verify that 

            the access token content matches with its expectations.=C2=A0
            However, 

            the authorization server and the resource server might
            decide to change the 

            token format at any time.=C2=A0 Thus, the client should not
            expect to always be 

            in a position to read the access token content.

            

            The remaining of the text about this topic is fine.

            

            

            3) The next topic is about the sub claim.

            

            The text states:

            

            Although
              the ability to correlate requests might be required by

              design in many scenarios, there are scenarios where the
              authorization

              server might want to prevent correlation to preserve the
              desired

              level of privacy. Authorization servers should choose how
              to assign

              sub values according to the level of privacy required by
              each

              situation.

            

            I have a set of questions: 

          
    
            
  1. 
              How can authorization servers choose how to assign sub
              values according to the level of privacy required "by ea=
ch
              situation" ?
    2. 
            
  2. 
              How can authorization servers know the level of privacy
              required "by each situation" ?
              
    3. 
            
  3. 
              How can the users be informed of the level of privacy
              required "by each situation" ?
    4. 
            
  4. 
              How can the users consent with the level of
              privacy required "by each situation" ?
    5. 
          

          
Currently,
            the request MUST include either a resource parameter or an
            aud claim parameter, while it MAY include a scope parameter.=


          
The
            syntax of the scope parameter is a list of space-delimited,
            case-sensitive strings (RFC 6749). It is thus subject to
            private agreements
            

            between clients and Authorization Servers. Since the scope
            is being returned, it is a primary importance that the
            returned scope matches
            

            with its expectations before transmitting the token to a
            Resource Server.

            

            In theory, a client should be able to choose whether it
            wishes the sub claim to contain :

          
    
            
  • 
              a global unique identifier for all ASs ("globally
              unique"),
    • 
            
  • 
              a unique identifier for each AS ("locally unique in the
              context of the issuer"),
    • 
            
  • 
              a different pseudonym for each RS, or 
    • 
            
  • 
              a different pseudonym for each authorization token
              request.
    • 
          

          
The
            only variable parameter that it can use for this purpose in
            the token request is the scope parameter.

            

            RFC 7519 states is section 4.1.2:

            

            The
              subject value MUST either be scoped to be locally unique
              in the context of the issuer
              

              or be globally unique.

            

            It is quite hard to recognize that the sub claim is able to
            carry a different pseudonym for each RS, i.e. for case (c),
            or
            

            a different pseudonym for each authorization token request,
            i.e. for case (d), which has nothing to do with uniqueness
            

            since the value changes for every generated token.

            

            This has implications about the following text:

            

            For
              instance: if a solution requires preventing tracking

              principal activities across multiple resource servers, the
              authorization server should ensure that JWT access tokens
              meant for

              different resource servers have distinct sub values that
              cannot be

              correlated in the event of resource servers collusion.

              

            Since it addresses case (c).

            

            and also about the following text:

            

            4.b)
              Similarly: if a solution requires preventing a resource
              server from
              

              correlating the principal=E2=80=99s activity within the resou=
rce
              itself, the 

              authorization server should assign different sub values
              for every JWT 

              access token issued.

            

            Since it addresses case (d).

            

            This means that the current text placed in the privacy
            considerations section was a good attempt to address the
            case,
            

            but that the text needs to be revised.

            

            Proposed text replacement for all the previously quoted
            sentences:

            

            According to RFC 7519 (4.1.2): The subject value MUST either
            be scoped to be locally unique in the context of the issuer
            or be globally unique.

            

            When the sub claim contains a globally unique identifier,
            this allows to correlate principal activities across
            multiple resource servers, while in addition,
            

            this globally unique identifier may also allow to correlate
            the principal activities on servers where no access has been
            performed by the principals
            

            to these servers but where the same globally unique
            identifiers are being used by these servers.
            

            

            When the sub claim contains a locally unique identifier in
            the context of the issuer, this also allows the tracking of
            principal activities across multiple resource servers.

            

            The scope request parameter is the only way to influence on
            the content of the sub claim parameter. Its meaning is
            subject to a private agreement
            

            between the client and the AS, which means that the use of
            the scope parameter is the only way to choose between a
            locally unique identifier
            

            in the context of the issuer or a globally unique
            identifier.

            

            Since the scope parameter is being returned, it is a primary
            importance that the returned scope matches with the
            expectations of the client before transmitting
            

            the token to a Resource Server.

            

            However, there are other cases where the client would like
            to be able to choose whether it wishes the sub claim to
            contain :
            

            =C2=A0=C2=A0=C2=A0 - a different pseudonym for each RS so that =
different
            resource servers will be unable to correlate its activities,
            or

            =C2=A0=C2=A0=C2=A0 - a different pseudonym for each authorizati=
on token
            request, so that the same resource server cannot correlate
            its activities performed at different instant of time.
            

            

            Considering the semantics of the sub claim, these two cases
            cannot be currently supported.

            

            

            4) The next topic is about the targeting of access
            tokens

          
Text
            had been proposed before the last conference call. Then, the
            topic has been presented at the very end of the last
            conference call, but no text has been included
            

            in the next draft. 

          
Here
            is a revised text be included in the privacy considerations
            section:

          
For
            security reasons, some clients may be willing to target
            their access tokens but, for privacy reasons, may be
            unwilling to disclose to Authorization Servers
            

            an identification of the Resource Servers they are going to
            access, so that Authorization Servers will be unable to know
            which resources servers are being accessed.
            

            The disclosure of the Resource Servers names allows the
            Authorization Servers to list all the Resource Servers being
            access by all its users and in addition to list pairs
            

            of (Principal, Resource Servers) which allow to trace all
            the users accesses to Resource Servers performed through a
            given Authorization Server. When a token is targeted,
            

            this profile does not contain provisions to address these
            two threats.

            

            Denis

        

        

          

            
Hi all,

            
=C2=A0=


            
This is a
              second working group last call for "JSON Web Token (JWT)
              Profile for OAuth 2.0 Access Tokens".

            
=C2=A0=


            
Here is the
              document:

            
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06=


            
=C2=A0=


            
Please send
              your comments to the OAuth mailing list by April 29, 2020.=


            
=C2=A0=


            
Regards,

            
=C2=A0Rifaat =
&
              Hannes

            
=C2=A0=


          

          


            

            

          
_______________________________________________

          
OAuth mailing list

          
OAuth@ie=
tf.org

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


        

        
=C2=A0

      

    

    


    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000988c6b05a59f805a--


From nobody Thu May 14 16:02:04 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09563A00DC for ; Thu, 14 May 2020 16:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level: 
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPex7FMdse2o for ; Thu, 14 May 2020 16:02:00 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640103.outbound.protection.outlook.com [40.107.64.103]) (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 515BB3A00D8 for ; Thu, 14 May 2020 16:02:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vtajyoeglawmdu+7ID1S6guiRPlEo3yNITfUBP35IDPW1THIl3DbR1KKS7Qj1a1xANtoQe8D4twxJzIRXVaPKT2TJgw4KEim5VfvROQ9xW14v3PSWl8ZkJrG4JE1b4ZiQp6/DAk2zbGU63RdIUtjEGYpsnq95OwBTa69Y/bOdDkxnjF6h17lTEQBm/YcSwgYX2azC0dvpjeXXaaqRtR6dwaoyszUrAQtHunZZKSnJ7UIVpErkgR23cvv59vx+i3PALNzuWyI3xapj74TiJkzLUAkKrj5KGHsZBm9fyDnuscONF3CwZRsxplP3W1bqJMghlO7T3kbYqF88FFfVptqjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bi4q3S2ayH7wfjLVD/FrlEuUv1feFLDRgVtZNIn9/lQ=; b=krtHxnRTOMIc0/MM8tkMdOyF02YFQqv0dGUkohMkhkME2roApHcg7DAP3MD3eeKhG+p02aaf9dCTQUaDp2s4robBUEWpjU8ZuscHsCYTAsBiniwDLbzT0BTfYnvYk3p7K//y7dY0StKVKj6AByMDNEfawabQCv/UYMG6yd8ioKKbkgX950JEuI0f7LoJMy9iEYEkTfL5b0im+QEONbmu6HXbrzlP7MZUKaObKOY+YhEYzCo+i7X97OTVThjZugNk6ZNp+vAzRa9ItH0soXVbfo/m/IOM7eZ4vVEMRQQxuYklw+LaEaN7uQ25zcQGqDyi/zdz9fTopmAPTWL/Glz/4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bi4q3S2ayH7wfjLVD/FrlEuUv1feFLDRgVtZNIn9/lQ=; b=Dpv1GUOAPNeT1tuxLEbdLN4aYw2RR1qHagRVC+C59zu6kB/i3XOivJT+/0WjMmqQ2EMe95Ky4XD8GVxkhliEaMDo731/3pxm9tUTBlCMQ1Fpt1lrEqbMBN7BGD1+1uEhn8V9o3fVgj6CM8kS545CHvnDL5ZlfZfyQOJBvLhAQrg=
Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0477.namprd00.prod.outlook.com (2603:10b6:208:c6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3035.0; Thu, 14 May 2020 23:01:58 +0000
Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283%7]) with mapi id 15.20.3035.000; Thu, 14 May 2020 23:01:58 +0000
From: Mike Jones 
To: Nov Matake , Torsten Lodderstedt 
CC: OAuth WG 
Thread-Topic: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
Thread-Index: AdYqQ6mP+sjI2ivKQUaZ77sbm4USDw==
Date: Thu, 14 May 2020 23:01:57 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d8e7b79f-5374-4899-8867-0000dc177252; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-14T22:47:59Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6ebadbb1-c95d-4806-ab79-08d7f85acdda
x-ms-traffictypediagnostic: MN2PR00MB0477:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 040359335D
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HfGFh+JzpHO30PUsmqT3jBRHBVsNyTkYSo+fqyOQDwKBqG6ksDWvQB6Lq7bSRWyZ0Qy5hz0Mt+E1KzfxzjKRb10Q7C+l+EvLTC8Jo8QI6eWZX5dWh9jBbv+AslF/so8cOBpxogebOCE5V9uuvwSD06ybUUxRhDVqFvBzUoKOG9l/C6Y/X+uLPux49HjbPx3mWUnhL5KwoNiZZMxpfcD9bu87rSjkaIetklvGxesEah+4cirAoVzBih4Kdo8KizpJRw/1aAusWoQp/c/p2qJ8AKpoNj+aZ5ktRwkMtEIH/qvbErw0pRxdDYsfUqrYCiKWAIxy1d8j3VtwOF+Cf5UUKzgOPXIQR6UXpqaKdQbNz4uK759NQUJw8b8PNAGv7eM7nwqemkkjdPu4NRvN6TGqSg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(136003)(39860400002)(366004)(396003)(376002)(53546011)(52536014)(110136005)(66476007)(966005)(76116006)(5660300002)(478600001)(64756008)(71200400001)(66556008)(10290500003)(6506007)(316002)(86362001)(26005)(8990500004)(33656002)(7696005)(66946007)(82960400001)(82950400001)(9686003)(66446008)(2906002)(8676002)(8936002)(55016002)(4326008)(186003); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: TZcSn3dznLiWbahkE1w4KSpDHsoJZoWhFE28LErI7zjUZtQU5QDjfr6NpOJaZHdH3g+v0N5T98OYkGIRVg9a3EeUfaetPr1nekcaouBQwQY+jhsYs2+YuDVZGRnS1W44hzczYOY5XaqNqlGwGVSRlXEn/TJiA81AoyhjXu6pOLoWiH5eZVWtO/J0SBYP/7EbOUN7HsQIExC27sp2Ww/MGeYmSNoLKyUtFJ0FJ/k1S9nieQ1kJCcaA7FUtH42cQp7xKML0qC9Ctm1KoyKu7OqRyqjVwWKSax3gCtW3LY93u5e/SX3tdZLGqNvHwnXdzBclnSIjgIaoEnssWGLyuLLxhr8LPV/jSjXkv90BrWGP98VOp5sZ81KseTxTaCabKVmqqUrly5KfNZuTBvvxE+n3TVTjQv1gZfLjVYgGvnWlzouzrNb+d8M383YLh4GIpgAF+nha6Uv7C4qo2BzmcEs8nkZrAvYmwHYRHuTxpva4mc=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ebadbb1-c95d-4806-ab79-08d7f85acdda
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 23:01:57.9614 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6KngrogljvLtZjGDoUp/j8epXj1M2sWgdNO4AiXjqtFcybDsKAK1951LinVradLQA4rMLujhcE4xOGVuII/5dQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0477
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 23:02:03 -0000

SSBhZ3JlZSB3aXRoIE5vdiB0aGF0IG9ic2N1cmluZyB0aGUgbGFuZ3VhZ2UgaW4gOS43IHdvdWxk
IGJlIGEgZGlzc2VydmljZSB0byBkZXZlbG9wZXJzLg0KDQpUaGUgU2VjdXJpdHkgQkNQLCB3aGlj
aCBoYXMgYWxyZWFkeSBnb2luZyB0aGUgV0dMQywgZXhwbGljaXRseSBjYWxscyBvdXQgdGhlIHVz
ZSBvZiBub25jZSBhcyBwYXJ0IG9mIHRoZSBiZXN0IHByYWN0aWNlcy4gIE9BdXRoIDIuMSBzaG91
bGQgZG8gbm8gbGVzcy4NCg0KVGhlIDkuNyBsYW5ndWFnZSB0aGF0IEFhcm9uIHByb3Bvc2VkIHdh
cyB0aGUgcmVzdWx0IG9mIG1hbnkgcGVvcGxlJ3MgY29udHJpYnV0aW9ucyBhbmQgYSB2aWdvcm91
cyBkaXNjdXNzaW9uLiAgTGV0J3MgcHVibGlzaCB0aGUgbmV4dCB2ZXJzaW9uIG9mIDIuMSB3aXRo
IHRoYXQgbGFuZ3VhZ2UgaW50YWN0LCBhcyBJIGJlbGlldmUgaXQgcmVwcmVzZW50cyBhdCBsZWFz
dCBhIGxvY2FsIHBvaW50IG9mIGhhcmQtd29uIGNvbnNlbnN1cy4gIExldCdzIGdldCB0aGF0IGxh
bmd1YWdlIGludG8gdGhlIHJlY29yZCBvZiBkcmFmdHMuDQoNClRoZXJlJ3MgYWx3YXlzIHRpbWUg
dG8gZGViYXRlIGl0IGFuZCBjaGFuZ2UgaXQgbGF0ZXIgaW4gc3Vic2VxdWVudCBkcmFmdHMsIGJ1
dCBsZXQncyBub3Qgbm93IGxvc2Ugd2hhdCBpdCB0b29rIGEgbG90IG9mIGVmZm9ydCB0byBhY2hp
ZXZlLg0KDQoJCQkJVGhhbmtzLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IE5vdiBNYXRha2UgPG1hdGFrZUBnbWFpbC5jb20+IA0KU2VudDogVGh1cnNk
YXksIE1heSAxNCwgMjAyMCAzOjE4IEFNDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rl
bkBsb2RkZXJzdGVkdC5uZXQ+DQpDYzogT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPjsgTWlrZSBK
b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmU6IFtPQVVUSC1X
R10gcHJvcG9zZWQgcmVzb2x1dGlvbiBmb3IgUEtDRSBpbiBPQXV0aCAyLjENCg0KVGhlcmUgaXMg
bm8gc3BlY2lmaWMgbWVjaGFuaXNtIHJpZ2h0IG5vdy4NCkJ1dCBmdXR1cmUgZGV2ZWxvcGVycyB3
b27igJl0IGJlIGFibGUgdG8gcmVhZCB0aGUgcmVhc29uIHdoeSB0aGUgZXh0ZW5zaW9uIHBvaW50
IGlzIGdpdmVuIG9ubHkgZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzLg0KDQo+IE9uIE1heSAxNCwg
MjAyMCwgYXQgMTg6MzIsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQu
bmV0PiB3cm90ZToNCj4gDQo+IEFyZSB5b3UgYXdhcmUgb2YgYW55IHN1aXRhYmxlIG1lY2hhbmlz
bT8gSeKAmW0gYXNraW5nIHNpbmNlIGZyb20gbXkgcGVyc3BlY3RpdmUgdGhpcyBjbGF1c2UgaXMg
bWFpbmx5IGludGVuZGVkIHRvIGFsbG93IGV4aXN0aW5nIE9wZW5JRCBDb25uZWN0IGRlcGxveW1l
bnRzIHRvIHVzZSBub25jZSBpbnN0ZWFkIG9mIFBLQ0UgaW4gY29tYmluYXRpb24gd2l0aCBPQXV0
aCAyLjEuIEl04oCZcyBhIGNvbXByb21pc2UuIEkgdGhpbmsgd2Ugc2hvdWxkIG5vdCBlbmNvdXJh
Z2Ugb3RoZXJzIHRvIGludmVudCB0aGVpciBvd24gT0F1dGggc2VjdXJpdHkgbWVjaGFuaXNtcy4g
DQo+IA0KPj4gT24gMTQuIE1heSAyMDIwLCBhdCAwOTozNywgTm92IE1hdGFrZSA8bWF0YWtlQGdt
YWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpLA0KPj4gDQo+PiBXaHkgbm90IGFsbG93aW5nIHB1
YmxpYyBjbGllbnRzIHVzZSAib3RoZXIgc3VpdGFibGUgbWVjaGFuaXNtc+KAnSB0aGVuPw0KPj4g
T0F1dGggV0cgY2FuIGFsbG93IGJvdGggdHlwZSBvZiBjbGllbnRzIGRvIHNvLCB0aGVuIE9JREYg
d2lsbCBkZWZpbmUgbm9uY2UgYXMgdGhlIGFsdGVybmF0aXZlIG9ubHkgZm9yIGNvbmZpZGVudGlh
bCBjbGllbnRzLg0KPj4gDQo+Pj4gMjAyMC8wNS8xNCAxNTo1NuOAgVRvcnN0ZW4gTG9kZGVyc3Rl
ZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+44Gu44Oh44O844Or
Og0KPj4+IA0KPj4+IEhpIGFsbCwNCj4+PiANCj4+PiBJIHdvdWxkIGFsc28gbGlrZSB0byB0aGFu
ayBldmVyeWJvZHkgZm9yIHRoZSBzdWJzdGFudGlhbCBkaXNjdXNzaW9uLiAgDQo+Pj4gDQo+Pj4g
VGhlIHByb3Bvc2VkIGNoYW5nZSBmb3IgU2VjdGlvbiA0LjEuMi4xIHdvcmtzIGZvciBtZSAoYXMg
YWxyZWFkeSBzdGF0ZWQpLiBJ4oCZbSBub3QgZnVsbHkgY29tZm9ydGFibGUgd2l0aCB0aGUgcHJv
cG9zZWQgY2hhbmdlIGZvciBTZWN0aW9uIDkuNyBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOg0K
Pj4+IA0KPj4+IC0gVGhlIHRleHQgaXMgd2Vha2VyIHRoYW4gU2VjdGlvbiA0LjEuMi4xIHNpbmNl
IGl0IFJFQ09NTUVORFMgdXNlIG9mIFBLQ0UgaW5zdGVhZCBvZiByZXF1aXJpbmcgaXQgKHdpdGgg
YSB3ZWxsLWRlZmluZWQgZXhjZXB0aW9uKS4NCj4+PiAtIEdpdmVuIHRoZSBsYXRlc3QgZmluZGlu
Z3MgcmUgbm9uY2UgSSBkb27igJl0IGZlZWwgY29tZm9ydGFibGUgd2l0aCByZWNvbW1lbmRpbmcg
YW55IG1lY2hhbmlzbSB0aGF0IHRoaXMgV0cgaXMgbm90IHJlc3BvbnNpYmxlIGZvciBhbmQgdGh1
cyBkaWQgbm90IGNvbmR1Y3QgdGhlIHNlY3VyaXR5IHRocmVhdCBhbmFseXNpcyBmb3IuIEkgdGhp
bmsgdGhlIGJldHRlciB3YXkgZm9yIHVzIGFzIFdHIGlzIHRvIGRlZmluZSB0aGUgZXh0ZW5zaW9u
IHBvaW50IGZvciBvdGhlciBtZWNoYW5pc21zLiBUaGUgT3BlbklEIEZvdW5kYXRpb24gKG9yIGFu
eSBvdGhlciBib2R5KSBjYW4gdGhlbiBmaWxsIGluIGFuZCBpc3N1ZSBhIHN0YXRlbWVudCB0aGF0
IG5vbmNlIChvciBhbm90aGVyIHN1aXRhYmxlIG1lY2hhbmlzbSkgZnVsZmlscyB0aGUgcmVxdWly
ZW1lbnRzIG9mIHRoZSBleHRlbnNpb24gcG9pbnQuIA0KPj4+IA0KPj4+IEJhc2VkIG9uIHRoaXMg
Y29uc2lkZXJhdGlvbnMsIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgZm9yIFNlY3Rpb24g
OS43Og0KPj4+IA0KPj4+IENsaWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlvbiAocmVwbGF5KSBv
ZiBhdXRob3JpemF0aW9uIGNvZGVzIGludG8gDQo+Pj4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9u
c2UgYnkgYXR0YWNrZXJzLiBQdWJsaWMgY2xpZW50cyBNVVNUIHVzZSB0aGUgDQo+Pj4gImNvZGVf
Y2hhbGxlbmdl4oCdIHdpdGggYSB0cmFuc2FjdGlvbi1zcGVjaWZpYyB2YWx1ZSB0aGF0IGlzIHNl
Y3VyZWx5IA0KPj4+IGJvdW5kIHRvIHRoZSBjbGllbnQgYW5kIHRoZSB1c2VyIGFnZW50IGluIHdo
aWNoIHRoZSB0cmFuc2FjdGlvbiB3YXMgDQo+Pj4gc3RhcnRlZC4gQ29uZmlkZW50aWFsIGNsaWVu
dHMgTVVTVCB1c2UgdGhlIOKAnGNvZGVfY2hhbGxlbmdl4oCdIGluIHRoZSANCj4+PiBzYW1lIHdh
eSBvciBvdGhlciBzdWl0YWJsZSBtZWNoYW5pc21zIHRvIG1pdGlnYXRlIGF1dGhvcml6YXRpb24g
Y29kZSANCj4+PiBpbmplY3Rpb24uDQo+Pj4gDQo+Pj4gVGhpcyB0ZXh0IGZvbGxvd3MgdGhlIGxv
Z2ljIGluIFNlY3Rpb24gNC4xLjIuMSBhbmQgYWxsb3dzIHVzZSBvZiB0aGUgbm9uY2UgZm9yIGNv
bmZpZGVudGlhbCBjbGllbnRzLg0KPj4+IA0KPj4+IGJlc3QgcmVnYXJkcywNCj4+PiBUb3JzdGVu
LiANCj4+PiANCj4+Pj4gT24gMTIuIE1heSAyMDIwLCBhdCAwMjoyMSwgTWlrZSBKb25lcyA8TWlj
aGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPj4+PiAN
Cj4+Pj4gVGhhdCB3b3JrcyBmb3IgbWUuICBUaGFua3MgYWxsIGZvciB0aGUgdXNlZnVsIGJhY2st
YW5kLWZvcnRoIHRoYXQgZ290IHVzIHRvIHRoaXMgcG9pbnQgb2YgY2xhcml0eS4gIEkgc3VzcGVj
dCBtYW55IG9mIHVzIGxlYXJuZWQgdGhpbmdzIGFsb25nIHRoZSB3YXk7IEkga25vdyB0aGF0IEkg
ZGlkIQ0KPj4+PiANCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIENoZWVycywNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+Pj4gDQo+Pj4+IEZyb206IEFhcm9uIFBh
cmVja2kgPGFhcm9uQHBhcmVja2kuY29tPg0KPj4+PiBTZW50OiBNb25kYXksIE1heSAxMSwgMjAy
MCA0OjU1IFBNDQo+Pj4+IFRvOiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQo+Pj4+IENjOiBO
ZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT47IE1pa2UgSm9uZXMgDQo+Pj4+
IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQo+Pj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgt
V0ddIHByb3Bvc2VkIHJlc29sdXRpb24gZm9yIFBLQ0UgaW4gT0F1dGggMi4xDQo+Pj4+IA0KPj4+
PiBUaGFuayB5b3UgTmVpbC4NCj4+Pj4gDQo+Pj4+IFRvIGFkZHJlc3MgTWlrZSdzIGNvbmNlcm5z
IGluIHRoZSBwcmV2aW91cyB0aHJlYWRzLCBJIHdvdWxkIGxpa2UgdG8gYWxzbyB1cGRhdGUgc2Vj
dGlvbiA5Ljcgd2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6DQo+Pj4+IA0KPj4+PiBDbGllbnRzIE1V
U1QgcHJldmVudCBpbmplY3Rpb24gKHJlcGxheSkgb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBpbnRv
IA0KPj4+PiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBieSBhdHRhY2tlcnMuIFRoZSB1c2Ug
b2YgdGhlIA0KPj4+PiBgY29kZV9jaGFsbGVuZ2VgIHBhcmFtZXRlciBpcyBSRUNPTU1FTkRFRCB0
byB0aGlzIGVuZC4gRm9yIA0KPj4+PiBjb25maWRlbnRpYWwgY2xpZW50cywgdGhlIE9wZW5JRCBD
b25uZWN0IGBub25jZWAgcGFyYW1ldGVyIGFuZCBJRCANCj4+Pj4gVG9rZW4gQ2xhaW0ge3tPcGVu
SUR9fSBNQVkgYmUgdXNlZCBpbnN0ZWFkIG9mIG9yIGluIGFkZGl0aW9uIHRvIHRoZSANCj4+Pj4g
YGNvZGVfY2hhbGxlbmdlYCBwYXJhbWV0ZXIgZm9yIHRoaXMgcHVycG9zZS4gVGhlIGBjb2RlX2No
YWxsZW5nZWAgDQo+Pj4+IG9yIE9wZW5JRCBDb25uZWN0IGBub25jZWAgdmFsdWUgTVVTVCBiZSB0
cmFuc2FjdGlvbi1zcGVjaWZpYyBhbmQgDQo+Pj4+IHNlY3VyZWx5IGJvdW5kIHRvIHRoZSBjbGll
bnQgYW5kIHRoZSB1c2VyIGFnZW50IGluIHdoaWNoIHRoZSB0cmFuc2FjdGlvbiB3YXMgc3RhcnRl
ZC4NCj4+Pj4gDQo+Pj4+IFRoaXMgY2hhbmdlIGJldHRlciBjbGFyaWZpZXMgdGhlIHNwZWNpZmlj
IGNpcmN1bXN0YW5jZXMgdW5kZXIgd2hpY2ggdGhlICJub25jZSIgcGFyYW1ldGVyIGlzIHN1ZmZp
Y2llbnQgdG8gcHJvdGVjdCBhZ2FpbnN0IGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uDQo+
Pj4+IA0KPj4+PiBBYXJvbiBQYXJlY2tpDQo+Pj4+IA0KPj4+PiBPbiBNb24sIE1heSAxMSwgMjAy
MCBhdCAxMTo1NSBBTSBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3Jv
dGU6DQo+Pj4+IEkgYW0gaGFwcHkgd2l0aCB0aGlzIHByb3Bvc2VkIHdvcmRpbmcuIFRoYW5rcyBm
b3IgdXBkYXRpbmcgaXQuDQo+Pj4+IA0KPj4+PiDigJQgTmVpbA0KPj4+PiANCj4+Pj4gDQo+Pj4+
IE9uIDExIE1heSAyMDIwLCBhdCAxOTo1MiwgQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5j
b20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gVGhhbmtzIGZvciB0aGUgbGl2ZWx5IGRpc2N1c3Npb24g
YXJvdW5kIFBLQ0UgaW4gT0F1dGggMi4xIGV2ZXJ5b25lISANCj4+Pj4gDQo+Pj4+IFdlIHdvdWxk
IGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQsIHdoaWNoIGlzIGEgc2xpZ2h0IHZh
cmlhdGlvbiBmcm9tIHRoZSB0ZXh0IE5laWwgcHJvcG9zZWQuIFRoaXMgd291bGQgcmVwbGFjZSB0
aGUgcGFyYWdyYXBoIGluIDQuMS4yLjEgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1wYXJlY2tpLW9hdXRoLXYyLTEtMDIjc2VjdGlvbi00LjEuMi4xKSB0aGF0IGJlZ2lucyB3aXRo
ICJJZiB0aGUgY2xpZW50IGRvZXMgbm90IHNlbmQgdGhlICJjb2RlX2NoYWxsZW5nZSIgaW4gdGhl
IHJlcXVlc3QuLi4iDQo+Pj4+IA0KPj4+PiAiQW4gQVMgTVVTVCByZWplY3QgcmVxdWVzdHMgd2l0
aG91dCBhIGNvZGVfY2hhbGxlbmdlIGZyb20gcHVibGljIGNsaWVudHMsIGFuZCBNVVNUIHJlamVj
dCBzdWNoIHJlcXVlc3RzIGZyb20gb3RoZXIgY2xpZW50cyB1bmxlc3MgdGhlcmUgaXMgcmVhc29u
YWJsZSBhc3N1cmFuY2UgdGhhdCB0aGUgY2xpZW50IG1pdGlnYXRlcyBhdXRob3JpemF0aW9uIGNv
ZGUgaW5qZWN0aW9uIGluIG90aGVyIHdheXMuIFNlZSBzZWN0aW9uIDkuNyBmb3IgZGV0YWlscy4i
DQo+Pj4+IA0KPj4+PiBTZWN0aW9uIDkuNyBpcyB3aGVyZSB0aGUgbnVhbmNlcyBvZiBQS0NFIHZz
IG5vbmNlIGFyZSBkZXNjcmliZWQuDQo+Pj4+IA0KPj4+PiBBcyBOZWlsIGRlc2NyaWJlZCwgd2Ug
YmVsaWV2ZSB0aGlzIHdpbGwgYWxsb3cgQVNzIHRvIHN1cHBvcnQgYm90aCBPQXV0aCAyLjAgYW5k
IDIuMSBjbGllbnRzIHNpbXVsdGFuZW91c2x5LiBUaGUgY2hhbmdlIGZyb20gTmVpbCdzIHRleHQg
aXMgdGhlIGNsYXJpZmljYXRpb24gb2Ygd2hpY2ggdGhyZWF0cywgYW5kIGNoYW5naW5nIHRvIE1V
U1QgaW5zdGVhZCBvZiBTSE9VTEQuIFRoZSAiTVVTVC4uLnVubGVzcyIgaXMgbW9yZSBzcGVjaWZp
YyB0aGFuICJTSE9VTEQiLCBhbmQgc2luY2Ugd2UgYXJlIGFscmVhZHkgZGVzY3JpYmluZyB0aGUg
ZXhwbGljaXQgZXhjZXB0aW9uIHRvIHRoZSBydWxlLCBpdCdzIG1vcmUgY2xlYXIgYXMgYSBNVVNU
IGhlcmUuDQo+Pj4+IA0KPj4+PiBBYXJvbiBQYXJlY2tpDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+
Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+Pj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+PiANCj4+Pj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gT0F1dGgg
bWFpbGluZyBsaXN0DQo+Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+
IE9BdXRoQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aA0KPj4gDQo+IA0KDQo=


From nobody Thu May 14 16:36:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC6B3A0789 for ; Thu, 14 May 2020 16:36:09 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fraF8KTPWQR3 for ; Thu, 14 May 2020 16:36:04 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836E83A079D for ; Thu, 14 May 2020 16:36:03 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id k18so775826ion.0 for ; Thu, 14 May 2020 16:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FHJBcWGMh/D15Z7EC83ru0aDLW/ycqaPnRQaQMOr31U=; b=l/xBDqnEWysuRPVGtVGzwxW6+Da177jncIZYqFad+7uZ2AuKDMoeW7t+P9mmCFna/d CESAcB7hu10H9R5xNUDJFEyzDyQulGbA08ykYSLSBAjnjax2KKWUm1l9Gezxpgca/AA8 VfG64EmjDgkStc2JtFbNx/hK36Luh8JiAt9f/tCikhD8wHiyoAXwTPc0pXJ4lQ6wwMaQ 72KM+buTSSHiSmSdncULqA4iNUTASbjQTd5LF7OhSiUioVByjqM8SNMsD00CtJp8d6Up 3KyiYhpdwtS4RSnB0HLPngJdXD20QUTkK92RbF09JeCHkq9IR1Jih0uEew5wg/nu3/Gq e0yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FHJBcWGMh/D15Z7EC83ru0aDLW/ycqaPnRQaQMOr31U=; b=sU/e0blyCDH7iaSjV+dQgqG8sVJrwUFfnzYhVeB1edYNnv00bWt3yM+tbODf4yInfX eehjuHDoYeHb/Df22dN/bIu+6Y0e3UBpfuyQZuZPbJ0kfHsFxoTMlwjucrSst3o0X2vY XsQP6Wsda8U9me8upW1EshBvbFmZNbxvPS75r6SxgfT6IJmgYY4Uql2gCvajDi4tYQOz XbW+sIgAlhEFqcREkjUraygpH0lwBXB5UwDflJRn7v1uXV78vEyx8RwLCngCpKalksXu xKPHxkpXeNaKFf0Ty0UIXJyuv/yOjvJVBDr8/RIyrR1elBTpk6Q2xEOgnbyGWlAPp/yO kPkQ==
X-Gm-Message-State: AOAM530RUE+7xJXhNhAWT5A1V1/nEBh/fT40CCCIegPU61G4lkXZub8/ XBaQNN6p1n21oKAXTi9x16vOOeWGvBs=
X-Google-Smtp-Source: ABdhPJzv7B/CXjH3o1HLx8kqHEHMMGYFNQNHr0fijAHcqjUWmCwIGD11hHW+dR+aUDa1nt/ky/Yj/Q==
X-Received: by 2002:a5d:8d1a:: with SMTP id p26mr491111ioj.131.1589499362222;  Thu, 14 May 2020 16:36:02 -0700 (PDT)
Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id s22sm163036iow.40.2020.05.14.16.36.00 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 May 2020 16:36:01 -0700 (PDT)
Received: by mail-il1-f171.google.com with SMTP id j2so667256ilr.5 for ; Thu, 14 May 2020 16:36:00 -0700 (PDT)
X-Received: by 2002:a92:3954:: with SMTP id g81mr665912ila.105.1589499360732;  Thu, 14 May 2020 16:36:00 -0700 (PDT)
MIME-Version: 1.0
References:  <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net> <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com> <1887D983-7A43-41C3-AAAD-786AD749240A@lodderstedt.net> <23145A44-5232-4312-9E51-627DB0FAFB44@gmail.com>
In-Reply-To: <23145A44-5232-4312-9E51-627DB0FAFB44@gmail.com>
From: Aaron Parecki 
Date: Thu, 14 May 2020 16:35:49 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Nov Matake 
Cc: Torsten Lodderstedt , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000c46c1e05a5a428d3"
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 23:36:17 -0000

--000000000000c46c1e05a5a428d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> There is no specific mechanism right now.
> But future developers won=E2=80=99t be able to read the reason why the ex=
tension
> point is given only for confidential clients.


This is not a compelling argument.

The current situation is that we know of a handful of threats and attacks,
we know that PKCE solves them for both confidential and public clients, and
we also believe that OpenID Connect has solved one of the threats for
confidential clients a different way. The reason this conversation is
happening at all is because we want to make sure that OpenID Connect can
continue to solve that problem its own way outside of OAuth without
conflicting with OAuth.

It's not useful to anyone to leave extension points open for hypothetical
solutions later when we already know of a solution that works for public
clients. At that point that should just be a new spec.

Aaron Parecki


On Thu, May 14, 2020 at 3:18 AM Nov Matake  wrote:

> There is no specific mechanism right now.
> But future developers won=E2=80=99t be able to read the reason why the ex=
tension
> point is given only for confidential clients.
>
> > On May 14, 2020, at 18:32, Torsten Lodderstedt 
> wrote:
> >
> > Are you aware of any suitable mechanism? I=E2=80=99m asking since from =
my
> perspective this clause is mainly intended to allow existing OpenID Conne=
ct
> deployments to use nonce instead of PKCE in combination with OAuth 2.1.
> It=E2=80=99s a compromise. I think we should not encourage others to inve=
nt their
> own OAuth security mechanisms.
> >
>
>

--000000000000c46c1e05a5a428d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--0000000000005a661305a5b35c51--


From nobody Fri May 15 12:24:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961B13A0809 for ; Fri, 15 May 2020 12:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqiUiozURsC2 for ; Fri, 15 May 2020 12:24:51 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE203A07CE for ; Fri, 15 May 2020 12:24:50 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id h4so3382371wmb.4 for ; Fri, 15 May 2020 12:24:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=fYtQAi/n1WP9OqdMuKJ8oI409Ptdfj1W7lRpSk/KCiY=; b=vYjdFgxY05CW/mDOl+A4pDBmkbHNSgiO4XXXZFD38eHg19XlG3Vt8E7ElHjBD6ba+P KQyQPe3c+ZeB7Z5hfzY0CiLdlucqOl2t26WTJ/5WomfoKtcch913OwBZ3F5DIqefGcNX wG/AG+S1yQ6jK8NsMxbgRhNK+KPRcisPoh25GQ8Dr3XM58JpICix5bshGZL1IPQV9mga ke/EgVGDMhJTd3CiF7cFOlABM0D+21Fim+NFdAzoRYNWzeoEvxPOapoXWLgNpAPSNCdU 3AVzriGYgIaV0bBDYSpq4DLPfy96K1AQO6UmW4cStl8MiNC950oqMomacKaEiSLCTdsV fjqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fYtQAi/n1WP9OqdMuKJ8oI409Ptdfj1W7lRpSk/KCiY=; b=CzUW8OtNHqXI0UstbL974SRwkaFJ5AMAik5AGjYn4pb5x5JL17+PS+aH+Azy7TlWP+ WeyZNrunCemB25ZifBqWvw3BxvTctrFh+K+Fv1ino8xiTEHwsxP6ggrJEXO04y1rdxbg Mp5nHSRW6MrWpWC+FVsnnlpdQk4ZZn6hJ6aNg1phCUCYucRxrD/NGtXGWG8K3i7Vx0fw XGWf6GjyWWk1xR+5w8sZsl3xAF3vQ5ZfCoqwB+R88MP2lQZhOU4GaeHBRCSB8370LmpF IsLcgvRib9cSZe54lgg8c+6nTr0GL9uK45uGTdW7P1n6SILkimuuU/o4r4FN5qPKZqu8 2eEw==
X-Gm-Message-State: AOAM533yvMqUD2s1IQ+SxG6LvujEOW/LaBVN6i4i0f5e+4c8dTOBLJFN h4r2bHodKeSOBZFCGodD4EaFiCsfKU38m98ivq2r0/Qa
X-Google-Smtp-Source: ABdhPJyGhy8hscCKavtv2mv8SAypoQ8bFIxvSN4dt4Xm1tiF7MwADt0PjWc/G5T6SXel1zgedeKKGI2KJIC8nriobdk=
X-Received: by 2002:a7b:c24b:: with SMTP id b11mr5478820wmj.101.1589570688805;  Fri, 15 May 2020 12:24:48 -0700 (PDT)
MIME-Version: 1.0
References: <83D4CBCE-E464-4CCC-8679-592531EF7448@ietf.org>
In-Reply-To: <83D4CBCE-E464-4CCC-8679-592531EF7448@ietf.org>
From: Rifaat Shekh-Yusef 
Date: Fri, 15 May 2020 15:24:38 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000406f7205a5b4c44f"
Archived-At: 
Subject: [OAUTH-WG] Fwd: IETF 108 will be an online meeting
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 19:24:53 -0000

--000000000000406f7205a5b4c44f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ---------
From: IETF Chair 
Date: Thu, May 14, 2020 at 5:08 PM
Subject: IETF 108 will be an online meeting
To: IETF-Announce , , IETF =
<
ietf@ietf.org>


The Internet Engineering Steering Group (IESG), the IETF LLC Board of
Directors, and the Internet Research Task Force (IRTF) Chair have decided
to replace the in-person IETF 108 Madrid meeting with an online meeting.
This decision is based on the IETF Executive Director=E2=80=99s recommendat=
ion,
which was made after conducting an assessment of local conditions using the
criteria set out in the assessment framework [1] developed with community
input.

The recommendation and full assessment are available at:
https://www.ietf.org/media/documents/IETF_108_Madrid_go_no-go_assessment.pd=
f

The online IETF 108 meeting will take place 27-31 July from 11:00 to 16:00
UTC each day. The end time of 16:00 UTC is approximate; some days may be
shorter depending on scheduling. These time blocks were chosen based on the
survey feedback [2] we received.

Further details about the online meeting will be shared as they become
available.

Sincerely,
Alissa Cooper, IETF Chair
Colin Perkins, IRTF Chair
Jason Livingood, IETF LLC Board Chair

[1]
https://www.ietf.org/blog/assessment-criteria-decision-personvirtual-ietf-1=
08/
?
[2]
https://www.ietf.org/media/documents/survey-planning-possible-online-meetin=
gs-responses.pdf
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--000000000000406f7205a5b4c44f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




---------- Forwarded message ---------
From: IETF Chair <chair@ietf.org>
Dat=
e: Thu, May 14, 2020 at 5:08 PM
Subject: IETF 108 will be an online meet=
ing
To: IETF-Announce <ietf=
-announce@ietf.org>,  <=
irtf-announce@irtf.org>, IETF <i=
etf@ietf.org>


The Internet Engineering Steering Gro=
up (IESG), the IETF LLC Board of Directors, and the Internet Research Task =
Force (IRTF) Chair have decided to replace the in-person IETF 108 Madrid me=
eting with an online meeting. This decision is based on the IETF Executive =
Director=E2=80=99s recommendation, which was made after conducting an asses=
sment of local conditions using the criteria set out in the assessment fram=
ework [1] developed with community input.



The recommendation and full assessment are available at: https://www.ietf.org/media/documents/IETF=
_108_Madrid_go_no-go_assessment.pdf



The online IETF 108 meeting will take place 27-31 July from 11:00 to 16:00 =
UTC each day. The end time of 16:00 UTC is approximate; some days may be sh=
orter depending on scheduling. These time blocks were chosen based on the s=
urvey feedback [2] we received.



Further details about the online meeting will be shared as they become avai=
lable.



Sincerely,

Alissa Cooper, IETF Chair

Colin Perkins, IRTF Chair

Jason Livingood, IETF LLC Board Chair



[1] https://www.ietf.o=
rg/blog/assessment-criteria-decision-personvirtual-ietf-108/?

[2] https=
://www.ietf.org/media/documents/survey-planning-possible-online-meetings-re=
sponses.pdf

_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announ=
ce




--000000000000406f7205a5b4c44f--


From nobody Fri May 15 20:48:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B81D3A0967 for ; Fri, 15 May 2020 20:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hobhXbVna5ir for ; Fri, 15 May 2020 20:48:13 -0700 (PDT)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164C33A0966 for ; Fri, 15 May 2020 20:48:13 -0700 (PDT)
Received: by mail-qv1-xf2c.google.com with SMTP id 59so2135870qva.13 for ; Fri, 15 May 2020 20:48:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/n7JiTvJ8bIRz2tU8Y4AzyC+YsuTr8V8puv3Os+dE+s=; b=B8avaRK7Et0K7q+JTjg/GQfMYGU1K7QhM28ER4RMOfXl7v4tT4U5M09IJK+2qhBs6f /zFs2Q8CyQa75GYiGJdQdKNMJYBDlJbQ/EHl42chEbr2dGGnA/lDvbzQr0kvXkEUZp1Y AqcJ/hkVbdT7iw3AUINlyF1VLY8Yez1Ao8inxWNiQa9p31o2cn4LZeVVLHL8IhNLN3FO yl3UFG7gOahDSvISv1R8/uLN8dUXXLPNne+IA6hL8zckzE8uguFIMByq7DOYtBaEXjPw Dfx/WyYaFu73UHwalUR6vhhRfAP7z4ykg27vVL0mfoIJ+EIUoZF1aIUZ28u8IqxIgaUe 6dUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/n7JiTvJ8bIRz2tU8Y4AzyC+YsuTr8V8puv3Os+dE+s=; b=k8SSGh5vjmxHkpr/3cCSu23zrP6B/BdG6HfDF+qPiFc3gl+puZ8/ZzfyWNvsvWvFfa irns9uml9F5220lWZEF9yx4vYbn9YfGYqDT4gFhQpc7SMJycclB57MKJw9ECskDDgJrS 9Q3eidBo2Kj9BtzXwirVzPO9VvU/W2SZEMT9yWCKmAZZk2zP0Jlx0QTBPh0caW5P4i6O NozQal1zy1KwI0dMJLUjfbs8V4COQ/ORXA3+2iHihznheGbL9VjmITHUtLt6txNxl6ld G3o5p5XDf33YCxpy5CNJ/WJWG8TqvMqWNewTJOqFhKKwNrbbz5B5bJ1HDrxINgf6anbB T32w==
X-Gm-Message-State: AOAM532idQlTW4qNFNzVavFUwt7q0+iBWCqovH9+AnoFymhDCWwYv2va Rbo6EIm9MVPMSwhjMuR6WrQ=
X-Google-Smtp-Source: ABdhPJygDgOnIcBzPr+Fwa2EdEaevDoPy37WD4lWKh2Cb6pa556Z06cbJdvRprml3PxwSZ46OgDIyQ==
X-Received: by 2002:a0c:f054:: with SMTP id b20mr6364016qvl.112.1589600891749;  Fri, 15 May 2020 20:48:11 -0700 (PDT)
Received: from jareds-mbp-2.lan ([72.214.174.120]) by smtp.gmail.com with ESMTPSA id h12sm3905594qte.31.2020.05.15.20.48.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 May 2020 20:48:10 -0700 (PDT)
To: Janak Amarasena , Denis 
Cc: oauth , Vittorio Bertocci 
References: <158608868945.18323.557347538112056951@ietfa.amsl.com> <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr>   <18e38735-ae9f-c41b-0cda-b2818a1038dc@danielfett.de> <7c27543f-6d14-2a5c-8a00-8b7d5baf17b1@free.fr> 
From: Jared L Jennings 
Message-ID: <6a8f47c9-6a38-b14c-ba0f-a3d70033db17@gmail.com>
Date: Fri, 15 May 2020 22:48:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4FB95D0ABD1107BBC032B73E"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 May 2020 03:48:15 -0000

This is a multi-part message in MIME format.
--------------4FB95D0ABD1107BBC032B73E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

To add to that, should it include the words "case sensitive" (if that is 
what is meant by exact), Although, URL's are not case sensitive in all 
cases, (IIS vs. Tomcat) which makes me think that specifying the case 
sensitivity is wise.

On 5/13/20 00:50, Janak Amarasena wrote:
> Hi All,
>
> In section *4.1.3. Countermeasures 
> * 
> related to *4.1.  Insufficient Redirect URI Validation* it states
>
>     The complexity of implementing and managing pattern matching
>     correctly obviously causes security issues.  This document therefore
>     advises to simplify the required logic and configuration by using
>     exact redirect URI matching only.  This means the authorization
>     server MUST compare the two URIs using simple string comparison as
>     defined in[RFC3986], Section 6.2.1  .
> Does this mean that the authorisation server MUST NOT use pattern 
> matching at all and MUST do simple string comparison for redirect URI?
> If that is the case can we change the wording a bit in this section as 
> having "...therefore *advises* to simplify the required logic..." 
> gives the impression that the AS has the choice to decide whether or 
> not to use pattern matching. And then when we have "...authorization 
> server *MUST* compare the two URIs using simple string..." give the 
> impression that the AS should absolutely not(MUST NOT) use pattern 
> matching.

-- 
-----
Jared L Jennings


--------------4FB95D0ABD1107BBC032B73E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
To add to that, should it include the words "case sensitive" (if
      that is what is meant by exact), Although, URL's are not case
      sensitive in all cases, (IIS vs. Tomcat) which makes me think that
      specifying the case sensitivity is wise.

    

    
On 5/13/20 00:50, Janak Amarasena
      wrote:

    

    
Hi
      All,
      


      

      
In section 4.1.3. Countermeasures
        related to 4.1.  Insufficient Redirect URI Validation it
        states

      


      

      

        
   The complexity of implementing and managing pattern matching
   correctly obviously causes security issues.  This document therefore
   advises to simplify the required logic and configuration by using
   exact redirect URI matching only.  This means the authorization
   server MUST compare the two URIs using simple string comparison as
   defined in [RFC3986], Section 6.2.1.

        

        Does this mean that the authorisation server MUST NOT use
        pattern matching at all and MUST do simple string comparison for
        redirect URI?

        If that is the case can we change the wording a bit in this
        section as having "...therefore advises to simplify the
        required logic..." gives the impression that the AS has the
        choice to decide whether or not to use pattern matching. And
        then when we have "...authorization server MUST compare
        the two URIs using simple string..." give the impression that
        the AS should absolutely not(MUST NOT) use pattern matching.

    

    
-- 
-----
Jared L Jennings

  


--------------4FB95D0ABD1107BBC032B73E--


From nobody Sat May 16 08:08:55 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C06B3A07E0 for ; Sat, 16 May 2020 08:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=lCi6aHFa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RmeIZmlt
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAUxBYZSMZI6 for ; Sat, 16 May 2020 08:08:52 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EB43A07C2 for ; Sat, 16 May 2020 08:08:52 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 057795D1 for ; Sat, 16 May 2020 11:08:50 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 16 May 2020 11:08:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:content-type :content-transfer-encoding:mime-version:subject:message-id:date :to; s=fm1; bh=h4y3MdgysriQ1mvK/tdcT5fhycgdLYB0Dox/nCzUwbk=; b=l Ci6aHFaU3G1SD83EmKOMNDhSTGD6oKP2TkwnWQu1bE7+U6eeOlooRRLLvwe+pu0o 68cA8/xHy7rjgosx8r9AbydvPFlFxPfqGC6ebScMzLdih//4pxyRZWg4gXT8EwL3 wBgdWb2GmNHKDpvFeiinnzrxGYJxDwDEMjOp4NagE80d/ewgOJSIlZlghpKySdFS HBbEqeCcMWTXTYmJcPh0rxUoUnquuCJmM/0GrsKmZNlaKjXXtRFw1dlEiaN35pFl M9Qib5xlZUSw31xt2bRAwjziTlkvUgY4nqj0+fn5CosXSti86ukKqDKbwt2zfGtn IMWKoZ3i3+K8TdqRVVFJw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=h4y3Md gysriQ1mvK/tdcT5fhycgdLYB0Dox/nCzUwbk=; b=RmeIZmlt/G3Ij0S0J2k0uL 9mF8rbNLtaqlWlMXQog/7NfLNuJl+dISMChDrPcMFZi1hG1IaWUJB820XkHeoPlB GNOLsECjzKKO29yCDuPbHoV6665gh7YhbQG56PykZDQ2udOHWyOGHMi8uccufgwC /cLQ4kdm7ZWoqgX4l+YdxhfopZenoBSQXUzA94xazlD8QIr8a1czPPAhqRfu4iX/ BihTvZdv5UzCFXKxTCrLoy63G9XPfcW7OE3HFCBm672h5DAkej51E91Gh2NFcQv0 5CRxUjrZChAziTxorHjzL8+1nkrWo2nvnVTkdEDSoNi61M41g2foupbgODVT+yEw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddttddgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd hhtddvnecuhfhrohhmpefrhhhilhhiphhpvgcuffgvucfthigtkhcuoehphhhilhhiphhp vgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtohhmqeenucggtffrrghtth gvrhhnpeehtdefveffgfeiheehkeelhfffheethefhffffuefhgfdttdehkeekgeelhfev udenucfkphepkedurdduieegrdduvdelrdelheenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitgif vggsshgvtghurhhithihrdgtohhm
X-ME-Proxy:    
Received: from philippes-mbp-2.localdomain (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id B59E9328005A for ; Sat, 16 May 2020 11:08:49 -0400 (EDT)
From: Philippe De Ryck 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Sat, 16 May 2020 17:08:48 +0200
To: oauth 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 May 2020 15:08:54 -0000

Hi all,

I am working on formulating developer guidelines on using Refresh Token =
Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps".=20

The protection offered by RTR kicks in the moment a refresh token is =
used twice, so the assumption is that the attacker has the ability to =
steal tokens from the client. In general, this means the attacker has =
malicious code running in the application (e.g., XSS, remote JS =
inclusion, ...).=20

Within these constraints, I can think of a couple of malicious payloads =
that sidestep the protection offered by RTR:

1. Stealing access tokens in an online XSS attack
2. Stealing refresh tokens, but waiting to use the latest until the =
original client is no longer active
3. Running a silent authentication flow in an iframe to obtain a new and =
unrelated AT and RT, and use that until it expires

Scenario 1 is straightforward in most applications, but the attack =
requires the vulnerable application to remain online. Scenario 2 might =
be difficult if the RT is kept out of reach from the main application =
(e.g. in a worker thread). Scenario 3 is most dangerous, but also a bit =
tricky to implement as the payload needs to make sure the application's =
code does not interfere (however, the browser's Same-Origin Policy will =
not intervene). The specifics depend on the concrete implementation, but =
all three attacks are technically feasible.

With these attacks in mind, it seems that the use of the Authorization =
Code flow with RTR does not really add much improvement for security, if =
other best practices are followed (e.g., using HTTPS). RTR does a lot =
for usability and handling third-party cookie blocking scenarios though.

In this context, my advice to developers is to avoid handling tokens in =
the browser in security-sensitive scenarios. A Backend-for-frontend =
pattern gives a server-side component control over tokens, along with =
the ability to implement additional security measures.

Additionally, is there any official recommendation to link the validity =
of a refresh token to the lifetime of the user's session with the =
Authorization Server? Having that property gives RTR similar security =
properties as the silent renew scenario.=20

Any feedback on this train of thought is more than welcome.

Philippe



From nobody Sat May 16 10:50:30 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FDF3A0A07 for ; Sat, 16 May 2020 10:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzSgcHJteO_M for ; Sat, 16 May 2020 10:50:26 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728233A09FF for ; Sat, 16 May 2020 10:50:26 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id s8so7066486wrt.9 for ; Sat, 16 May 2020 10:50:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G4w6x/Qa/p0JIObczuVRBGCMCZ1TIR0mowq4jschhRQ=; b=Usg3eWRKW1vEXgrZMoYOT0m1dVgigOAZEWoIJJ7vIzyn4MmSYF4EP4P2xlzGFlYpFf yTocGtHL3OVJbW1mIZpC3dZvC0faqx7bWlvYLpuM3qZEIvHvB1cwecbf3JMsjdrJvaJl 7b4+fulv+Rnrdy21qSXJb+nA3Pm/PkamEV0E+Do/fAzjEDuZuyGARWlS6H553w4rE+Ra /y4iqLFYA2BwaFqSqTlKXG+90NfD6TfF0SxkH7xIhkB76iukpaOodhnpBuxHtm+SNJ+M HP4KYlTYDzIbryQU7PsFUSGiwxbY8hvTH/1jejOOQ79xsXHwkU4239rGdd3PlKJBdXxl b3Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G4w6x/Qa/p0JIObczuVRBGCMCZ1TIR0mowq4jschhRQ=; b=pm8AQHEYaYILvn5afGSLIj+NldntBOnOM5Nx0RJNRkcVneSa8oBie8h2AeQ1/Vrqtq JK8QyhIgZ0r79FKeEM64Fzga7ZrJk1kcxCvCOgBV0Ul4Rp6fZFatYhRO/YpcKbYocI80 urGdRxwRpA77XN+BpqsHQgALEmmgMVeqJTtYS0UGA6+uB+wK5Vev+7PbsI9WsZV8O8q/ 43JdIPr2UObEhCTUM63QJZeHkYnGxRRZXOObhjCPnLdmguWd+4or1HrUsO8ugRdpy1nK 1DFi0ePFthXjZ2zU8QGxq7H2bqj/QkDcrKIjbSQRejQUku7jJx8inlEPW+ZwPLZbePYx hqKA==
X-Gm-Message-State: AOAM5319PFYGh1DyD5bBJxHbvWKZjNZlXIrEyKTw/90ivF9dqP6IGhjU GbF6fcdpuHAOwMsTEy/oGeoGw4GIm0M=
X-Google-Smtp-Source: ABdhPJwewbDw6LnEGmjBEpPc2KBSPoLm1G4RRAzTPluRpa83GUUzPTtiuMAnKg6bktuEo1CH7/HpvA==
X-Received: by 2002:adf:e404:: with SMTP id g4mr10438946wrm.418.1589651424663;  Sat, 16 May 2020 10:50:24 -0700 (PDT)
Received: from p200300eb8f301f5bf4b00d3ed436139b.dip0.t-ipconnect.de (p200300EB8F301F5BF4B00D3ED436139B.dip0.t-ipconnect.de. [2003:eb:8f30:1f5b:f4b0:d3e:d436:139b]) by smtp.gmail.com with ESMTPSA id o205sm8705941wmo.32.2020.05.16.10.50.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2020 10:50:24 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Sat, 16 May 2020 19:50:23 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A9DFEB7-9503-4034-9F33-4B2DC399CE4F@lodderstedt.net>
References: 
To: Philippe De Ryck 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 May 2020 17:50:28 -0000

Hi Philippe,=20

> On 16. May 2020, at 17:08, Philippe De Ryck =
 wrote:
>=20
> Hi all,
>=20
> I am working on formulating developer guidelines on using Refresh =
Token Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps".=20=

>=20
> The protection offered by RTR kicks in the moment a refresh token is =
used twice, so the assumption is that the attacker has the ability to =
steal tokens from the client. In general, this means the attacker has =
malicious code running in the application (e.g., XSS, remote JS =
inclusion, ...).=20
>=20
> Within these constraints, I can think of a couple of malicious =
payloads that sidestep the protection offered by RTR:
>=20
> 1. Stealing access tokens in an online XSS attack
> 2. Stealing refresh tokens, but waiting to use the latest until the =
original client is no longer active
> 3. Running a silent authentication flow in an iframe to obtain a new =
and unrelated AT and RT, and use that until it expires
>=20
> Scenario 1 is straightforward in most applications, but the attack =
requires the vulnerable application to remain online. Scenario 2 might =
be difficult if the RT is kept out of reach from the main application =
(e.g. in a worker thread). Scenario 3 is most dangerous, but also a bit =
tricky to implement as the payload needs to make sure the application's =
code does not interfere (however, the browser's Same-Origin Policy will =
not intervene). The specifics depend on the concrete implementation, but =
all three attacks are technically feasible.
>=20
> With these attacks in mind, it seems that the use of the Authorization =
Code flow with RTR does not really add much improvement for security, if =
other best practices are followed (e.g., using HTTPS). RTR does a lot =
for usability and handling third-party cookie blocking scenarios though.

I also see this as the main advantage of RTs.

I think scenario 3 can be made more difficult for the attacker by =
requiring user interaction. That=E2=80=99s ok since the normal case =
would be to refresh via RT and not via authorization flow, so the legit =
app shouldn=E2=80=99t be affected.=20

>=20
> In this context, my advice to developers is to avoid handling tokens =
in the browser in security-sensitive scenarios. A Backend-for-frontend =
pattern gives a server-side component control over tokens, along with =
the ability to implement additional security measures.

I full agree with those advice. Handling security sensitive aspects of =
the app out of reach of the user (which might be an attacker) is a good =
idea. On the functional side, this also gives the app access to =
authentication and sender constrained access tokens via mTLS.

>=20
> Additionally, is there any official recommendation to link the =
validity of a refresh token to the lifetime of the user's session with =
the Authorization Server? Having that property gives RTR similar =
security properties as the silent renew scenario.=20

Section 4.12.2. of the Security BCP recommends refresh token revocation =
in case of logout.=20

best regards,
Torsten.=20

>=20
> Any feedback on this train of thought is more than welcome.
>=20
> Philippe
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sat May 16 11:21:38 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ADF3A0062 for ; Sat, 16 May 2020 11:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level: 
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=CqirIaAr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mc7NlDcg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZF6HZ5LtLUd for ; Sat, 16 May 2020 11:21:35 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D99C3A0061 for ; Sat, 16 May 2020 11:21:35 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 2D888434; Sat, 16 May 2020 14:21:34 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 16 May 2020 14:21:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm1; bh=qUR3g42KCDlNRdDHCgXSWMti2RIL2cufFBVTc6Kf/Aw=; b=CqirIaArwp1z /knVRisceSfcrJ0x3j4xhoY5kxoaoF+1RxivE/kxO+swaeCg4J+BYE8+th08uGIG H/3r8RECwu+qcvLQ0fAPg/ReMdxVQOzlQmNLdvhxlznuu7ZnV16t4hXCDgbtkUyU PSjjbOKr7XbWCD/Dnk2Scs8l1Cqlqp7VhkA76BB8+FtRrMBpYlzP+yEP958Bc52r 152P9yyW9HCKHcTb6CdwqvBYSnyFOhO1P4rI2BV++1QsZIEGsm5WZnoBGC6R0oO5 rEDMLbcl0gpf35UsTYrT4TAwm5+fJpStvHAnswmmQfTwEcTP0sY/V1as03KyhicY FB+wB4opQg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qUR3g4 2KCDlNRdDHCgXSWMti2RIL2cufFBVTc6Kf/Aw=; b=Mc7NlDcgF3PJtute8YCXis W+H2YF9rG4N8HEasQoqO14yT4K2PV/oY+0Gbkii9ba/nrHp+KvXYWOjc5Xz5za9y QqoNPXR0A958Q0XmYCmMXAgLZgBiDNVKR/DeOprKqXQM8opqQbNLqUnRUmZ10412 f0fihwKsyMSD5GC0gaYHNJkYj+DHpVg2F+NMf185QSDW844XCuM67wqmek+DbfbT opKwOmq1Tiz9LS7ut5BXBZmmvi4WzGRigbbSRzE/YVn6ujjhL4GRMyM+iyBXqTDy 2asai0sCRsYF+7e9kWT7CyV+UEVQKJkqD5ps8d/MhfOxXY4oJzxptOET90lDer4g ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddttddguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheprfhhihhl ihhpphgvucffvgcutfihtghkuceophhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsg hsvggtuhhrihhthidrtghomheqnecuggftrfgrthhtvghrnhepgedvueegvefhvedvjedv iedtheekteegtdffffdvueejheevuddtffeglefgvdeunecuffhomhgrihhnpehmohiiih hllhgrrdhorhhgpdhivghtfhdrohhrghenucfkphepkedurdduieegrdduvdelrdelheen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilh hiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtohhm
X-ME-Proxy:    
Received: from imacvanphilippe.localdomain (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id E0486306638F; Sat, 16 May 2020 14:21:32 -0400 (EDT)
From: Philippe De Ryck 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4244A1A6-4EA0-4057-97E4-DD46BD8C891E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 16 May 2020 20:21:31 +0200
In-Reply-To: <4A9DFEB7-9503-4034-9F33-4B2DC399CE4F@lodderstedt.net>
Cc: oauth 
To: Torsten Lodderstedt 
References:  <4A9DFEB7-9503-4034-9F33-4B2DC399CE4F@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 May 2020 18:21:37 -0000

--Apple-Mail=_4244A1A6-4EA0-4057-97E4-DD46BD8C891E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Torsten,

> On 16 May 2020, at 19:50, Torsten Lodderstedt =
 wrote:
>=20
> Hi Philippe,=20
>=20
>> On 16. May 2020, at 17:08, Philippe De Ryck =
 wrote:
>>=20
>> Hi all,
>>=20
>> I am working on formulating developer guidelines on using Refresh =
Token Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps".=20=

>>=20
>> The protection offered by RTR kicks in the moment a refresh token is =
used twice, so the assumption is that the attacker has the ability to =
steal tokens from the client. In general, this means the attacker has =
malicious code running in the application (e.g., XSS, remote JS =
inclusion, ...).=20
>>=20
>> Within these constraints, I can think of a couple of malicious =
payloads that sidestep the protection offered by RTR:
>>=20
>> 1. Stealing access tokens in an online XSS attack
>> 2. Stealing refresh tokens, but waiting to use the latest until the =
original client is no longer active
>> 3. Running a silent authentication flow in an iframe to obtain a new =
and unrelated AT and RT, and use that until it expires
>>=20
>> Scenario 1 is straightforward in most applications, but the attack =
requires the vulnerable application to remain online. Scenario 2 might =
be difficult if the RT is kept out of reach from the main application =
(e.g. in a worker thread). Scenario 3 is most dangerous, but also a bit =
tricky to implement as the payload needs to make sure the application's =
code does not interfere (however, the browser's Same-Origin Policy will =
not intervene). The specifics depend on the concrete implementation, but =
all three attacks are technically feasible.
>>=20
>> With these attacks in mind, it seems that the use of the =
Authorization Code flow with RTR does not really add much improvement =
for security, if other best practices are followed (e.g., using HTTPS). =
RTR does a lot for usability and handling third-party cookie blocking =
scenarios though.
>=20
> I also see this as the main advantage of RTs.
>=20
> I think scenario 3 can be made more difficult for the attacker by =
requiring user interaction. That=E2=80=99s ok since the normal case =
would be to refresh via RT and not via authorization flow, so the legit =
app shouldn=E2=80=99t be affected.=20

Preventing a silent flow from happening would indeed stop this attack =
vector, but it might create usability problems in single page =
applications.

A typical scenario is an SPA running a silent authentication flow in an =
iframe when it is first started. This allows the app to bootstrap itself =
with the user=E2=80=99s authentication status if a session already =
exists. This pattern is common when tokens are kept in memory, as a =
simple page reload causes that state to be cleared. Since Safari and =
Brave already block third-party cookies, they cannot run a silent flow =
in an iframe. A workaround would be to run a top-level silent =
redirect-based flow to check if an authenticated session exists or not. =
The impact on the UX for this initial redirect is limited, since it is =
silent anyway. By turning off a silent flow, both use cases would stop =
working.=20

I totally get that this is a quite challenging problem to address. Given =
your suggestion, the authorization server could prevent iframe-based =
flows when RTs are used, but still allow top-level navigation flows for =
the bootstrap phase. Right now, I don=E2=80=99t think we can implement =
such a detection mechanism in a reliable way, but hopefully the upcoming =
Sec-Fetch-Dest header can help here =
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest =
=
)

>=20
>>=20
>> In this context, my advice to developers is to avoid handling tokens =
in the browser in security-sensitive scenarios. A Backend-for-frontend =
pattern gives a server-side component control over tokens, along with =
the ability to implement additional security measures.
>=20
> I full agree with those advice. Handling security sensitive aspects of =
the app out of reach of the user (which might be an attacker) is a good =
idea. On the functional side, this also gives the app access to =
authentication and sender constrained access tokens via mTLS.

That=E2=80=99s precisely my recommendation as well.=20

>>=20
>> Additionally, is there any official recommendation to link the =
validity of a refresh token to the lifetime of the user's session with =
the Authorization Server? Having that property gives RTR similar =
security properties as the silent renew scenario.=20
>=20
> Section 4.12.2. of the Security BCP recommends refresh token =
revocation in case of logout.=20

Right, I should have checked that more closely for the details. I also =
see it recommends the timeout after inactivity, which corresponds =
somewhat to linking it to the session lifetime (which would have similar =
properties).=20

Thanks!

Philippe

>=20
> best regards,
> Torsten.=20
>=20
>>=20
>> Any feedback on this train of thought is more than welcome.
>>=20
>> Philippe
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_4244A1A6-4EA0-4057-97E4-DD46BD8C891E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Torsten,



On 16 May 2020, at 19:50, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Philippe, 

On =
16. May 2020, at 17:08, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:

Hi all,

I am =
working on formulating developer guidelines on using Refresh Token =
Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps". 

The protection offered by RTR kicks in the moment a refresh =
token is used twice, so the assumption is that the attacker has the =
ability to steal tokens from the client. In general, this means the =
attacker has malicious code running in the application (e.g., XSS, =
remote JS inclusion, ...). 

Within these constraints, I can think of a couple of =
malicious payloads that sidestep the protection offered by RTR:

1. Stealing access tokens in an online XSS =
attack
2. Stealing refresh tokens, but waiting to use the =
latest until the original client is no longer active
3. =
Running a silent authentication flow in an iframe to obtain a new and =
unrelated AT and RT, and use that until it expires

Scenario 1 is straightforward in most applications, but the =
attack requires the vulnerable application to remain online. Scenario 2 =
might be difficult if the RT is kept out of reach from the main =
application (e.g. in a worker thread). Scenario 3 is most dangerous, but =
also a bit tricky to implement as the payload needs to make sure the =
application's code does not interfere (however, the browser's =
Same-Origin Policy will not intervene). The specifics depend on the =
concrete implementation, but all three attacks are technically =
feasible.

With these attacks in mind, it =
seems that the use of the Authorization Code flow with RTR does not =
really add much improvement for security, if other best practices are =
followed (e.g., using HTTPS). RTR does a lot for usability and handling =
third-party cookie blocking scenarios though.

I also see this as the main advantage of RTs.

I think scenario 3 can be made =
more difficult for the attacker by requiring user interaction. That=E2=80=99=
s ok since the normal case would be to refresh via RT and not via =
authorization flow, so the legit app shouldn=E2=80=99t be affected. 

Preventing =
a silent flow from happening would indeed stop this attack vector, but =
it might create usability problems in single page =
applications.

A typical scenario is =
an SPA running a silent authentication flow in an iframe when it is =
first started. This allows the app to bootstrap itself with the user=E2=80=
=99s authentication status if a session already exists. This pattern is =
common when tokens are kept in memory, as a simple page reload causes =
that state to be cleared. Since Safari and Brave already block =
third-party cookies, they cannot run a silent flow in an iframe. A =
workaround would be to run a top-level silent redirect-based flow to =
check if an authenticated session exists or not. The impact on the UX =
for this initial redirect is limited, since it is silent anyway. By =
turning off a silent flow, both use cases would stop =
working. 

I totally get that =
this is a quite challenging problem to address. Given your suggestion, =
the authorization server could prevent iframe-based flows when RTs are =
used, but still allow top-level navigation flows for the bootstrap =
phase. Right now, I don=E2=80=99t think we can implement such a =
detection mechanism in a reliable way, but hopefully the upcoming =
Sec-Fetch-Dest header can help here (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-F=
etch-Dest)



In this context, my =
advice to developers is to avoid handling tokens in the browser in =
security-sensitive scenarios. A Backend-for-frontend pattern gives a =
server-side component control over tokens, along with the ability to =
implement additional security measures.

I full agree with those advice. =
Handling security sensitive aspects of the app out of reach of the user =
(which might be an attacker) is a good idea. On the functional side, =
this also gives the app access to authentication and sender constrained =
access tokens via mTLS.

That=E2=80=99s precisely my recommendation as =
well. 


Additionally, is there any official recommendation to link =
the validity of a refresh token to the lifetime of the user's session =
with the Authorization Server? Having that property gives RTR similar =
security properties as the silent renew scenario. 

Section 4.12.2. of the Security BCP recommends refresh token =
revocation in case of logout. 

Right, I =
should have checked that more closely for the details. I also see it =
recommends the timeout after inactivity, which corresponds somewhat to =
linking it to the session lifetime (which would have similar =
properties). 

Thanks!

Philippe


best regards,
Torsten. 


Any feedback on this train of thought is more than =
welcome.

Philippe


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

=

--Apple-Mail=_4244A1A6-4EA0-4057-97E4-DD46BD8C891E--


From nobody Sat May 16 12:16:54 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B743A0400 for ; Sat, 16 May 2020 12:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK5u1_41ukDG for ; Sat, 16 May 2020 12:16:52 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6303A03F7 for ; Sat, 16 May 2020 12:16:52 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id k7so2549715pjs.5 for ; Sat, 16 May 2020 12:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=Dkhq7m1CYZlpoelqKYbFHpHlDT+kmS7gB8hTo/dhwZU=; b=CshTAOQfOx6SFr6GXt+tsFdxDDiJgnY5JJgJykf2WT0hHF2Ve9+HzRKhOhHC6midJ+ 9VoyYQmsRFj0kYS3A/4El28OIE4w2TsLqPlj3uJEBcE7dlVJbQdr0nSfO7h6MEZvmXO+ 4C6HIbqurjkDYg27ig9eWYG0WJl1VrBhRyW5WeoaD5GqM/Jr5UimBH5rGWWzuHwFHxvk E5ZlMVK6Rj4uKk36TWSmalxCe9qDAK2EFG4yucM+lvICN07qDgJji7LpG3SC6qxXY4Yn nc3pqTqknGhOFJVGaOagBYQZM3zjMYtf12xpkQCCVRpswZxBC6Hzv/ZwxA3iV9X0g3qQ EntA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=Dkhq7m1CYZlpoelqKYbFHpHlDT+kmS7gB8hTo/dhwZU=; b=nHYn5uSoXPMXeilfTiAYlhKiiIZORpN01UeNrAMFkmAQX+BgvYRbUKztTX411pb9k4 9SEtXtvjz1MzwOAcznNzkRz7/Nb2UAZeNSWtlPAClkO5JQK8FkCtnmuA9+31n0E/uS38 VZe/3MK/1e32velv1+V1S56hBMomADpJbIv5oKeEx9hCiZExrIM0G58C7XPtX60l/RCr 1ke8duYq1Jh23zrX0zLiTdUkxgG4lJOKTT5tHp0UWJ2gOie6BXkUWjUt+aqV1Loqx8Qn U7V0mmVnS+sb1/sr7vt+/QWUfs1Suy2Nr6YjEj6SOAEGJTAA8eiEHwPgsUP9qyqo8CZO RJWg==
X-Gm-Message-State: AOAM533pqYYkp4cki3jdc6kBOI+GbBOq/HU2HchSD1Qk/TQjUWB1EEX0 RO4I+PLD5nbPEP+2pzC+ww+N/WgKJcU=
X-Google-Smtp-Source: ABdhPJwF7jjSjmeGLIezHN955ZiN2/ODKu1U2GiVfWvmPJkKMGzaysqfDxAUa7JpyjO1ng0dGKCzYA==
X-Received: by 2002:a17:90a:248c:: with SMTP id i12mr6993896pje.213.1589656611402;  Sat, 16 May 2020 12:16:51 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id d20sm4473015pgl.72.2020.05.16.12.16.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2020 12:16:50 -0700 (PDT)
From: Vittorio Bertocci 
To: Torsten Lodderstedt , Philippe De Ryck 
CC: oauth 
Thread-Topic: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation
Thread-Index: ATNCNDQyTv4ZmcxvTFygbG77L6x+sEZDMzQ3w6DrFa4=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sat, 16 May 2020 19:16:48 +0000
Message-ID: 
References:  <4A9DFEB7-9503-4034-9F33-4B2DC399CE4F@lodderstedt.net>
In-Reply-To: <4A9DFEB7-9503-4034-9F33-4B2DC399CE4F@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 May 2020 19:16:54 -0000

PiBsb2dvdXQgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQoNCk9uZSBpbXBvcnRhbnQgZGV0
YWlsIGhlcmUgaXMgdGhhdCBpZiB0aGUgcmVmcmVzaCB0b2tlbiBoYXMgYmVlbiBvYnRhaW5lZCBi
eSBpbmNsdWRpbmcgdGhlIHNjb3BlICJvZmZsaW5lX2FjY2VzcyIsIHRoZW4gaXRzIGxpZmV0aW1l
IHNob3VsZCBub3QgYmUgdGllZCB0byB0aGUgbGlmZXRpbWUgb2YgdGhlIHNlc3Npb24gKHNlZSBo
dHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNPZmZs
aW5lQWNjZXNzKSwgaGVuY2UgcmV2b2tpbmcgaXQgb24gbG9nb3V0IHdvdWxkIGJlIHZpb2xhdGlu
ZyB0aGUgY29udHJhY3QgdGhydSB3aGljaCBpdCBoYXMgYmVlbiBvYnRhaW5lZC4gVGhpbmsgY2xh
c3NpYyBzY2hlZHVsZWQgdHdlZXRzIHNjZW5hcmlvcywgYSB3ZWIgYXBwIHR3ZWV0aW5nIG9uIG15
IGJlaGFsZiBhdCBhIGdpdmVuIHRpbWUgc2hvdWxkIHJldGFpbiB0aGUgYWJpbGl0eSB0byBnZXQg
dG9rZW5zIGZvciBjYWxsaW5nIHRoZSB0d2l0dGVyIEFQSSByZWdhcmRsZXNzIG9mIHdoZXRoZXIg
SSBhbSBzaWduZWQgaW4gdGhlIHdlYiBhcHAgYXQgdGhlIG1vbWVudCBvZiB0aGUgY2FsbC4NCkZv
ciBtYW55IHBsYXRmb3JtcywgcmVxdWVzdGluZyInb2ZmbGluZV9hY2Nlc3MiIGlzIHRoZSBvbmx5
IHdheSBvZiBvYnRhaW5pbmcgYSByZWZyZXNoIHRva2VuLSBoZW5jZSB0aGlzIHBvaW50IGlzIGlt
cG9ydGFudCBhcyBpdCBoYXMgd2lkZSBpbXBhY3QgaW4gcG9wdWxhciBwbGF0Zm9ybXMuDQpUaGF0
J3MgYWxzbyB3aHkgdGhlcmUgd2FzIGEgcHJvcG9zYWwgdG8gaW50cm9kdWNlIGFuICJvbmxpbmVf
YWNjZXNzIiBzY29wZSB0byBtYWtlIHRoaXMgZGlmZmVyZW5jZSBleHBsaWNpdCwgYnV0IEkgaGF2
ZW4ndCBmb2xsb3dlZCB0aGF0IGVmZm9ydCBpbiBhIHdoaWxlLg0KDQoNCu+7v09uIDUvMTYvMjAs
IDEwOjUwLCAiT0F1dGggb24gYmVoYWxmIG9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQiIDxvYXV0aC1i
b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRt
YXJjLmlldGYub3JnPiB3cm90ZToNCg0KICAgIEhpIFBoaWxpcHBlLCANCiAgICANCiAgICA+IE9u
IDE2LiBNYXkgMjAyMCwgYXQgMTc6MDgsIFBoaWxpcHBlIERlIFJ5Y2sgPHBoaWxpcHBlQHByYWdt
YXRpY3dlYnNlY3VyaXR5LmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEhpIGFsbCwNCiAgICA+
IA0KICAgID4gSSBhbSB3b3JraW5nIG9uIGZvcm11bGF0aW5nIGRldmVsb3BlciBndWlkZWxpbmVz
IG9uIHVzaW5nIFJlZnJlc2ggVG9rZW4gUm90YXRpb24gKFJUUiksIGFzIHJlcXVpcmVkIGJ5ICJP
QXV0aCAyLjAgZm9yIEJyb3dzZXItQmFzZWQgQXBwcyIuIA0KICAgID4gDQogICAgPiBUaGUgcHJv
dGVjdGlvbiBvZmZlcmVkIGJ5IFJUUiBraWNrcyBpbiB0aGUgbW9tZW50IGEgcmVmcmVzaCB0b2tl
biBpcyB1c2VkIHR3aWNlLCBzbyB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBhdHRhY2tlciBo
YXMgdGhlIGFiaWxpdHkgdG8gc3RlYWwgdG9rZW5zIGZyb20gdGhlIGNsaWVudC4gSW4gZ2VuZXJh
bCwgdGhpcyBtZWFucyB0aGUgYXR0YWNrZXIgaGFzIG1hbGljaW91cyBjb2RlIHJ1bm5pbmcgaW4g
dGhlIGFwcGxpY2F0aW9uIChlLmcuLCBYU1MsIHJlbW90ZSBKUyBpbmNsdXNpb24sIC4uLikuIA0K
ICAgID4gDQogICAgPiBXaXRoaW4gdGhlc2UgY29uc3RyYWludHMsIEkgY2FuIHRoaW5rIG9mIGEg
Y291cGxlIG9mIG1hbGljaW91cyBwYXlsb2FkcyB0aGF0IHNpZGVzdGVwIHRoZSBwcm90ZWN0aW9u
IG9mZmVyZWQgYnkgUlRSOg0KICAgID4gDQogICAgPiAxLiBTdGVhbGluZyBhY2Nlc3MgdG9rZW5z
IGluIGFuIG9ubGluZSBYU1MgYXR0YWNrDQogICAgPiAyLiBTdGVhbGluZyByZWZyZXNoIHRva2Vu
cywgYnV0IHdhaXRpbmcgdG8gdXNlIHRoZSBsYXRlc3QgdW50aWwgdGhlIG9yaWdpbmFsIGNsaWVu
dCBpcyBubyBsb25nZXIgYWN0aXZlDQogICAgPiAzLiBSdW5uaW5nIGEgc2lsZW50IGF1dGhlbnRp
Y2F0aW9uIGZsb3cgaW4gYW4gaWZyYW1lIHRvIG9idGFpbiBhIG5ldyBhbmQgdW5yZWxhdGVkIEFU
IGFuZCBSVCwgYW5kIHVzZSB0aGF0IHVudGlsIGl0IGV4cGlyZXMNCiAgICA+IA0KICAgID4gU2Nl
bmFyaW8gMSBpcyBzdHJhaWdodGZvcndhcmQgaW4gbW9zdCBhcHBsaWNhdGlvbnMsIGJ1dCB0aGUg
YXR0YWNrIHJlcXVpcmVzIHRoZSB2dWxuZXJhYmxlIGFwcGxpY2F0aW9uIHRvIHJlbWFpbiBvbmxp
bmUuIFNjZW5hcmlvIDIgbWlnaHQgYmUgZGlmZmljdWx0IGlmIHRoZSBSVCBpcyBrZXB0IG91dCBv
ZiByZWFjaCBmcm9tIHRoZSBtYWluIGFwcGxpY2F0aW9uIChlLmcuIGluIGEgd29ya2VyIHRocmVh
ZCkuIFNjZW5hcmlvIDMgaXMgbW9zdCBkYW5nZXJvdXMsIGJ1dCBhbHNvIGEgYml0IHRyaWNreSB0
byBpbXBsZW1lbnQgYXMgdGhlIHBheWxvYWQgbmVlZHMgdG8gbWFrZSBzdXJlIHRoZSBhcHBsaWNh
dGlvbidzIGNvZGUgZG9lcyBub3QgaW50ZXJmZXJlIChob3dldmVyLCB0aGUgYnJvd3NlcidzIFNh
bWUtT3JpZ2luIFBvbGljeSB3aWxsIG5vdCBpbnRlcnZlbmUpLiBUaGUgc3BlY2lmaWNzIGRlcGVu
ZCBvbiB0aGUgY29uY3JldGUgaW1wbGVtZW50YXRpb24sIGJ1dCBhbGwgdGhyZWUgYXR0YWNrcyBh
cmUgdGVjaG5pY2FsbHkgZmVhc2libGUuDQogICAgPiANCiAgICA+IFdpdGggdGhlc2UgYXR0YWNr
cyBpbiBtaW5kLCBpdCBzZWVtcyB0aGF0IHRoZSB1c2Ugb2YgdGhlIEF1dGhvcml6YXRpb24gQ29k
ZSBmbG93IHdpdGggUlRSIGRvZXMgbm90IHJlYWxseSBhZGQgbXVjaCBpbXByb3ZlbWVudCBmb3Ig
c2VjdXJpdHksIGlmIG90aGVyIGJlc3QgcHJhY3RpY2VzIGFyZSBmb2xsb3dlZCAoZS5nLiwgdXNp
bmcgSFRUUFMpLiBSVFIgZG9lcyBhIGxvdCBmb3IgdXNhYmlsaXR5IGFuZCBoYW5kbGluZyB0aGly
ZC1wYXJ0eSBjb29raWUgYmxvY2tpbmcgc2NlbmFyaW9zIHRob3VnaC4NCiAgICANCiAgICBJIGFs
c28gc2VlIHRoaXMgYXMgdGhlIG1haW4gYWR2YW50YWdlIG9mIFJUcy4NCiAgICANCiAgICBJIHRo
aW5rIHNjZW5hcmlvIDMgY2FuIGJlIG1hZGUgbW9yZSBkaWZmaWN1bHQgZm9yIHRoZSBhdHRhY2tl
ciBieSByZXF1aXJpbmcgdXNlciBpbnRlcmFjdGlvbi4gVGhhdOKAmXMgb2sgc2luY2UgdGhlIG5v
cm1hbCBjYXNlIHdvdWxkIGJlIHRvIHJlZnJlc2ggdmlhIFJUIGFuZCBub3QgdmlhIGF1dGhvcml6
YXRpb24gZmxvdywgc28gdGhlIGxlZ2l0IGFwcCBzaG91bGRu4oCZdCBiZSBhZmZlY3RlZC4gDQog
ICAgDQogICAgPiANCiAgICA+IEluIHRoaXMgY29udGV4dCwgbXkgYWR2aWNlIHRvIGRldmVsb3Bl
cnMgaXMgdG8gYXZvaWQgaGFuZGxpbmcgdG9rZW5zIGluIHRoZSBicm93c2VyIGluIHNlY3VyaXR5
LXNlbnNpdGl2ZSBzY2VuYXJpb3MuIEEgQmFja2VuZC1mb3ItZnJvbnRlbmQgcGF0dGVybiBnaXZl
cyBhIHNlcnZlci1zaWRlIGNvbXBvbmVudCBjb250cm9sIG92ZXIgdG9rZW5zLCBhbG9uZyB3aXRo
IHRoZSBhYmlsaXR5IHRvIGltcGxlbWVudCBhZGRpdGlvbmFsIHNlY3VyaXR5IG1lYXN1cmVzLg0K
ICAgIA0KICAgIEkgZnVsbCBhZ3JlZSB3aXRoIHRob3NlIGFkdmljZS4gSGFuZGxpbmcgc2VjdXJp
dHkgc2Vuc2l0aXZlIGFzcGVjdHMgb2YgdGhlIGFwcCBvdXQgb2YgcmVhY2ggb2YgdGhlIHVzZXIg
KHdoaWNoIG1pZ2h0IGJlIGFuIGF0dGFja2VyKSBpcyBhIGdvb2QgaWRlYS4gT24gdGhlIGZ1bmN0
aW9uYWwgc2lkZSwgdGhpcyBhbHNvIGdpdmVzIHRoZSBhcHAgYWNjZXNzIHRvIGF1dGhlbnRpY2F0
aW9uIGFuZCBzZW5kZXIgY29uc3RyYWluZWQgYWNjZXNzIHRva2VucyB2aWEgbVRMUy4NCiAgICAN
CiAgICA+IA0KICAgID4gQWRkaXRpb25hbGx5LCBpcyB0aGVyZSBhbnkgb2ZmaWNpYWwgcmVjb21t
ZW5kYXRpb24gdG8gbGluayB0aGUgdmFsaWRpdHkgb2YgYSByZWZyZXNoIHRva2VuIHRvIHRoZSBs
aWZldGltZSBvZiB0aGUgdXNlcidzIHNlc3Npb24gd2l0aCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2
ZXI/IEhhdmluZyB0aGF0IHByb3BlcnR5IGdpdmVzIFJUUiBzaW1pbGFyIHNlY3VyaXR5IHByb3Bl
cnRpZXMgYXMgdGhlIHNpbGVudCByZW5ldyBzY2VuYXJpby4gDQogICAgDQogICAgU2VjdGlvbiA0
LjEyLjIuIG9mIHRoZSBTZWN1cml0eSBCQ1AgcmVjb21tZW5kcyByZWZyZXNoIHRva2VuIHJldm9j
YXRpb24gaW4gY2FzZSBvZiBsb2dvdXQuIA0KICAgIA0KICAgIGJlc3QgcmVnYXJkcywNCiAgICBU
b3JzdGVuLiANCiAgICANCiAgICA+IA0KICAgID4gQW55IGZlZWRiYWNrIG9uIHRoaXMgdHJhaW4g
b2YgdGhvdWdodCBpcyBtb3JlIHRoYW4gd2VsY29tZS4NCiAgICA+IA0KICAgID4gUGhpbGlwcGUN
CiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KICAgID4gT0F1dGggbWFpbGluZyBsaXN0DQogICAgPiBPQXV0aEBpZXRm
Lm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K
ICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQogICAgT0F1dGggbWFpbGluZyBsaXN0DQogICAgT0F1dGhAaWV0Zi5vcmcNCiAgICBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgDQo=


From nobody Mon May 18 03:04:34 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CCA3A0A67 for ; Mon, 18 May 2020 03:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyFqXtAZcTgn for ; Mon, 18 May 2020 03:04:30 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760973A0A64 for ; Mon, 18 May 2020 03:04:30 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id ACC2DF40753; Mon, 18 May 2020 03:04:26 -0700 (PDT)
To: n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com, naa@google.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: dmitry.khlebnikov@rea-group.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200518100426.ACC2DF40753@rfc-editor.org>
Date: Mon, 18 May 2020 03:04:26 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 May 2020 10:04:33 -0000

The following errata report has been submitted for RFC7636,
"Proof Key for Code Exchange by OAuth Public Clients".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6179

--------------------------------------
Type: Technical
Reported by: Dmitry Khlebnikov 

Section: 7.3

Original Text
-------------
7.3.  Salting the code_challenge

   To reduce implementation complexity, salting is not used in the
   production of the code challenge, as the code verifier contains
   sufficient entropy to prevent brute-force attacks.  Concatenating a
   publicly known value to a code verifier (containing 256 bits of
   entropy) and then hashing it with SHA256 to produce a code challenge
   would not increase the number of attempts necessary to brute force a
   valid value for code verifier.

   While the "S256" transformation is like hashing a password, there are
   important differences.  Passwords tend to be relatively low-entropy
   words that can be hashed offline and the hash looked up in a
   dictionary.  By concatenating a unique though public value to each
   password prior to hashing, the dictionary space that an attacker
   needs to search is greatly expanded.

   Modern graphics processors now allow attackers to calculate hashes in
   real time faster than they could be looked up from a disk.  This
   eliminates the value of the salt in increasing the complexity of a
   brute-force attack for even low-entropy passwords.

Corrected Text
--------------


Notes
-----
The section misrepresents the information about "salting" and the whole idea 
of "salting" is not applicable to a standalone hash.  I suggest to drop the entire
section as irrelevant to the rest of the standard.

For some reason the section implies that "salting" is protecting and increasing
entropy of a single hash, which is not what "salting" is about and is not the
reason for the technique.  The section is also making a speculative assumptions
about the low-entropy tendency in password hashes and makes an incorrect
conclusion on the benefits of "salting" for a password hash.

One could argue that the entropy and the complexity required to bruteforce a hash
and a salted hash for the same password (where the same hashing algorithm is
applied) are approximately the same in most cases (or just slightly more
complex for the salted version if the producer of the hash used a non-standard
routine in relation of mixing in the salt, e.g. instead of appending the salt
it inserts in in the middle of the password to be hashed).  In any case, that
public data is already known to the attacker and it is just a matter of the
configuration for the bruteforcing tool (such as JohnTheRipper) to incorporate
the knowledge.

Just as an illustration: consider an example password ('abc'), an example salt
('123'), and that the hash is generated using a concatinated version of these
two (e.g. HASH('abc123')).  Since the salt is included with the hash in plain
text, the bruteforcer would just need to set their tool up with the "^.*123$"
pattern making the salt essentially a string terminator which is not affecting
the bruteforce effort in any way).

More and more people I meet are confused about the problem area the "salting"
technique was invented to address: it is to increase the entropy of a set of
passwords, so the same password would not result in the same hash value, with
the primary goal is to prevent attackers to be able to re-use pre-calculated
hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to
make it impossible to quickly assess what hashes the attacker should focus on
(e.g.  when you have 1000 hashes and without salts you can easily spot that
some hashes are the same, which means breaking these one would gain much more
in comparison to unique hashes in the same set).

This being said, I am suggesting to drop section 7.3 completely as irrelevant, 
since what we currently have is very confusing and seeds unnecessary and
wrong ideas that "salting" can improve the security of a single hash by itself.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7636 (draft-ietf-oauth-spop-15)
--------------------------------------
Title               : Proof Key for Code Exchange by OAuth Public Clients
Publication Date    : September 2015
Author(s)           : N. Sakimura, Ed., J. Bradley, N. Agarwal
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Mon May 18 09:54:48 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98603A08CF for ; Mon, 18 May 2020 09:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level: 
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCtFKrzSZTkq for ; Mon, 18 May 2020 09:54:43 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850963A08D5 for ; Mon, 18 May 2020 09:54:43 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id E94A24B12 for ; Mon, 18 May 2020 16:54:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1589820880; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Pts14g6OtWAOpLjACN5b07gPXLWEg3ehOr9Xie5p4g=; b=b9lgWMf5sNFBjhT4l7nyHZDIRfzFeOfYQnUTtB2x1fOLh3eQHagfa1JKZdpj9m/AhoYLH8 1YWuwzJ2Xd6vK5O/ltoj15Psbxyr5dalwVVB+I+tEFh/nzmR44xSxEC203zxv0uzTeZdM2 qoelZgz9jgEt8k8W3VwhyU/j81Qic+o=
To: "oauth@ietf.org" 
References: 
From: Daniel Fett 
Message-ID: <1bc5387b-d9a1-fa36-83d8-15756e9a1a51@danielfett.de>
Date: Mon, 18 May 2020 18:54:39 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------136F8E4B5EF0B4B0B3C0460E"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1589820880; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Pts14g6OtWAOpLjACN5b07gPXLWEg3ehOr9Xie5p4g=; b=gbTnr+HJeXQ+7cCbW6reFQwUCDjtJw4SkqqpUCN59ZC/mZCOJAW3euYCq3fhWB3uDF/ca5 0L4UaVWvU3bwPg4wDe3TGFe2K8BvsSs9+TPiR40+d+9EHm100S644BJcESsJW3uFYV9c6E VuGeu9l/W7JoToH3o3uDCH2I9VDxjJ4=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1589820880; a=rsa-sha256; cv=none; b=SeI1U8Uyza0Cko8WmjzAeYBl5V995fdBhFUl+xIFhreJQp3WiCcECRjxAzlK9qxUCN8dUT l/EPers8xjDoHYug9M3WUUpZ9ILaBXqg7QkUEzZ+EUmRZsbdXXihndKGV0fXBVfrG5YzLp RhhNMqwna584Ne2TW2cVLQtjU9wjXX4=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 May 2020 16:54:47 -0000

This is a multi-part message in MIME format.
--------------136F8E4B5EF0B4B0B3C0460E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Hi all,

Talking to Torsten, we realized that providing a generic extension point
here is probably not a good idea. It is really hard to tell what
protects you from code injection and what does not, and people might
come up with all sorts of non-standard and potentially insecure solutions.

Even just for PKCE vs. Nonce, it is not obvious if they provide the same
level of protection. In an attempt to answer this question, I tried to
come up with a more systematic analysis of "PKCE vs Nonce". I wrote up
my results here:
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

Although this is not a formal analysis, I hope that I have covered all
interesting cases. Please review the text and let me know if I have
missed something or if there are any mistakes.

The main results are:

 1. In terms of protection against CSRF and code misuse, PKCE and Nonce
    provide similar levels of security, with a slight advantage for PKCE.
 2. In practice, a circumvention of both mechanisms, however, is
    possible if an AS allows a client to choose between PKCE and Nonce
    and the client makes use of this freedom. I propose to call this
    attack the Nonce/PKCE Sidestep Attack. → Please review the attack
    description in the analysis.
 3. To avoid the Nonce/PKCE Sidestep Attack, clients must not switch
    between using only PKCE and only Nonce (but may use both in
    parallel, or switch between using only PKCE and PKCE+Nonce).
    Authorization servers must enforce PKCE unless they know that the
    client uses Nonce for all of its flows (and checks the Nonce value).
    The presence of a nonce parameter in the authorization request is
    not sufficient to determine if a client actually checks the nonce
    claim in the ID token.

As you can see, already having two more-or-less well-understood
mechanisms is hard enough to wrap your head around from a security
standpoint. We should therefore make PKCE the default and Nonce an
option for backwards compatibility.

To this end, I would like to propose the follwing strawman, based on
Torsten's and Aaron's suggestions:

An AS MUST reject requests without a code_challenge from public
clients, and MUST reject such requests from other clients unless there
is reasonable assurance that the client mitigates authorization code
injection using the OpenID Connect Nonce mechanism and that this
mitigation is used for all interactions with the client. See section
9.7 for details.

Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers. The use of the
`code_challenge` parameter is RECOMMENDED to this end. For
confidential clients, the OpenID Connect `nonce` parameter and ID
Token Claim {{OpenID}} MAY be used instead of or in addition to the
`code_challenge` parameter for this purpose. The `code_challenge` or
OpenID Connect `nonce` value MUST be transaction-specific and securely
bound to the client and the user agent in which the transaction was
started.

If the OpenID Connect `nonce` is used to mitigate authorization code
injection instead of `code_challenge`, client and authorization server
MUST ensure that the mitigation is applied to every interaction with
the client and that the client cannot switch between `code_challenge`
and `nonce`. For example, the presence of a `nonce` parameter in the
authorization request is not sufficient to determine that the
`code_verifier` check can be skipped.


Of course, we need to adapt the wording in the Security BCP accordingly.

-Daniel



Am 15.05.20 um 01:01 schrieb Mike Jones:
> I agree with Nov that obscuring the language in 9.7 would be a disservice to developers.
>
> The Security BCP, which has already going the WGLC, explicitly calls out the use of nonce as part of the best practices.  OAuth 2.1 should do no less.
>
> The 9.7 language that Aaron proposed was the result of many people's contributions and a vigorous discussion.  Let's publish the next version of 2.1 with that language intact, as I believe it represents at least a local point of hard-won consensus.  Let's get that language into the record of drafts.
>
> There's always time to debate it and change it later in subsequent drafts, but let's not now lose what it took a lot of effort to achieve.
>
> 				Thanks,
> 				-- Mike
>
> -----Original Message-----
> From: Nov Matake  
> Sent: Thursday, May 14, 2020 3:18 AM
> To: Torsten Lodderstedt 
> Cc: OAuth WG ; Mike Jones 
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
> There is no specific mechanism right now.
> But future developers won’t be able to read the reason why the extension point is given only for confidential clients.
>
>> On May 14, 2020, at 18:32, Torsten Lodderstedt  wrote:
>>
>> Are you aware of any suitable mechanism? I’m asking since from my perspective this clause is mainly intended to allow existing OpenID Connect deployments to use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I think we should not encourage others to invent their own OAuth security mechanisms. 
>>
>>> On 14. May 2020, at 09:37, Nov Matake  wrote:
>>>
>>> Hi,
>>>
>>> Why not allowing public clients use "other suitable mechanisms” then?
>>> OAuth WG can allow both type of clients do so, then OIDF will define nonce as the alternative only for confidential clients.
>>>
>>>> 2020/05/14 15:56、Torsten Lodderstedt のメール:
>>>>
>>>> Hi all,
>>>>
>>>> I would also like to thank everybody for the substantial discussion.  
>>>>
>>>> The proposed change for Section 4.1.2.1 works for me (as already stated). I’m not fully comfortable with the proposed change for Section 9.7 for the following reasons:
>>>>
>>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE instead of requiring it (with a well-defined exception).
>>>> - Given the latest findings re nonce I don’t feel comfortable with recommending any mechanism that this WG is not responsible for and thus did not conduct the security threat analysis for. I think the better way for us as WG is to define the extension point for other mechanisms. The OpenID Foundation (or any other body) can then fill in and issue a statement that nonce (or another suitable mechanism) fulfils the requirements of the extension point. 
>>>>
>>>> Based on this considerations, I propose the following text for Section 9.7:
>>>>
>>>> Clients MUST prevent injection (replay) of authorization codes into 
>>>> the authorization response by attackers. Public clients MUST use the 
>>>> "code_challenge” with a transaction-specific value that is securely 
>>>> bound to the client and the user agent in which the transaction was 
>>>> started. Confidential clients MUST use the “code_challenge” in the 
>>>> same way or other suitable mechanisms to mitigate authorization code 
>>>> injection.
>>>>
>>>> This text follows the logic in Section 4.1.2.1 and allows use of the nonce for confidential clients.
>>>>
>>>> best regards,
>>>> Torsten. 
>>>>
>>>>> On 12. May 2020, at 02:21, Mike Jones  wrote:
>>>>>
>>>>> That works for me.  Thanks all for the useful back-and-forth that got us to this point of clarity.  I suspect many of us learned things along the way; I know that I did!
>>>>>
>>>>>                                                     Cheers,
>>>>>                                                     -- Mike
>>>>>
>>>>> From: Aaron Parecki 
>>>>> Sent: Monday, May 11, 2020 4:55 PM
>>>>> To: OAuth WG 
>>>>> Cc: Neil Madden ; Mike Jones 
>>>>> 
>>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>>>
>>>>> Thank you Neil.
>>>>>
>>>>> To address Mike's concerns in the previous threads, I would like to also update section 9.7 with the following text:
>>>>>
>>>>> Clients MUST prevent injection (replay) of authorization codes into 
>>>>> the authorization response by attackers. The use of the 
>>>>> `code_challenge` parameter is RECOMMENDED to this end. For 
>>>>> confidential clients, the OpenID Connect `nonce` parameter and ID 
>>>>> Token Claim {{OpenID}} MAY be used instead of or in addition to the 
>>>>> `code_challenge` parameter for this purpose. The `code_challenge` 
>>>>> or OpenID Connect `nonce` value MUST be transaction-specific and 
>>>>> securely bound to the client and the user agent in which the transaction was started.
>>>>>
>>>>> This change better clarifies the specific circumstances under which the "nonce" parameter is sufficient to protect against authorization code injection.
>>>>>
>>>>> Aaron Parecki
>>>>>
>>>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden  wrote:
>>>>> I am happy with this proposed wording. Thanks for updating it.
>>>>>
>>>>> — Neil
>>>>>
>>>>>
>>>>> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>>>>>
>>>>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! 
>>>>>
>>>>> We would like to propose the following text, which is a slight variation from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins with "If the client does not send the "code_challenge" in the request..."
>>>>>
>>>>> "An AS MUST reject requests without a code_challenge from public clients, and MUST reject such requests from other clients unless there is reasonable assurance that the client mitigates authorization code injection in other ways. See section 9.7 for details."
>>>>>
>>>>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>>>>
>>>>> As Neil described, we believe this will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is the clarification of which threats, and changing to MUST instead of SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we are already describing the explicit exception to the rule, it's more clear as a MUST here.
>>>>>
>>>>> Aaron Parecki
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------136F8E4B5EF0B4B0B3C0460E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi all,

    


    

    
Talking to Torsten, we realized that
      providing a generic extension point here is probably not a good
      idea. It is really hard to tell what protects you from code
      injection and what does not, and people might come up with all
      sorts of non-standard and potentially insecure solutions. 

    

    


    

    
Even just for PKCE vs. Nonce, it is not
      obvious if they provide the same level of protection. In an
      attempt to answer this question, I tried to come up with a more
      systematic analysis of "PKCE vs Nonce". I wrote up my results
      here: 

    

    
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

    

    

    Although this is not a formal analysis, I hope that I have covered
    all interesting cases. Please review the text and let me know if I
    have missed something or if there are any mistakes.

    

    The main results are:

    
    
      
  1. In terms of protection against CSRF and code misuse, PKCE and
        Nonce provide similar levels of security, with a slight
        advantage for PKCE.
    2. 
      
  2. In practice, a circumvention of both mechanisms, however, is
        possible if an AS allows a client to choose between PKCE and
        Nonce and the client makes use of this freedom. I propose to
        call this attack the Nonce/PKCE Sidestep Attack. → Please review
        the attack description in the analysis.
    3. 
      
  3. To avoid the Nonce/PKCE Sidestep Attack, clients must not
        switch between using only PKCE and only Nonce (but may use both
        in parallel, or switch between using only PKCE and PKCE+Nonce).
        Authorization servers must enforce PKCE unless they know that
        the client uses Nonce for all of its flows (and checks the Nonce
        value). The presence of a nonce parameter in the authorization
        request is not sufficient to determine if a client actually
        checks the nonce claim in the ID token.
    4. 
    

    
As you can see, already having two more-or-less well-understood
      mechanisms is hard enough to wrap your head around from a security
      standpoint. We should therefore make PKCE the default and Nonce an
      option for backwards compatibility.

    

    
To this end, I would like to propose the follwing strawman, based
      on Torsten's and Aaron's suggestions:

    An AS MUST reject requests without a code_challenge from public

    clients, and MUST reject such requests from other clients
      unless there

    is reasonable assurance that the client mitigates
      authorization code

    injection using the OpenID Connect Nonce mechanism and that
      this

    mitigation is used for all interactions with the client.
      See section

    9.7 for details.

    

    Section 9.7:

    

    Clients MUST prevent injection (replay) of authorization codes
      into

    the authorization response by attackers. The use of the

    `code_challenge` parameter is RECOMMENDED to this end. For

    confidential clients, the OpenID Connect `nonce` parameter
      and ID

    Token Claim {{OpenID}} MAY be used instead of or in
      addition to the

    `code_challenge` parameter for this purpose. The
      `code_challenge` or

    OpenID Connect `nonce` value MUST be transaction-specific
      and securely

    bound to the client and the user agent in which the
      transaction was

    started.

    

    If the OpenID Connect `nonce` is used to mitigate
      authorization code

    injection instead of `code_challenge`, client and
      authorization server

    MUST ensure that the mitigation is applied to every
      interaction with

    the client and that the client cannot switch between
      `code_challenge`

    and `nonce`. For example, the presence of a `nonce`
      parameter in the

    authorization request is not sufficient to determine that
      the

    `code_verifier` check can be skipped.

    


    

    
Of course, we need to adapt the wording in the Security BCP
      accordingly.

    
-Daniel

    

    


    

    


    

    
Am 15.05.20 um 01:01 schrieb Mike
      Jones:

    

    

      
I agree with Nov that obscuring the language in 9.7 would be a disservice to developers.

The Security BCP, which has already going the WGLC, explicitly calls out the use of nonce as part of the best practices.  OAuth 2.1 should do no less.

The 9.7 language that Aaron proposed was the result of many people's contributions and a vigorous discussion.  Let's publish the next version of 2.1 with that language intact, as I believe it represents at least a local point of hard-won consensus.  Let's get that language into the record of drafts.

There's always time to debate it and change it later in subsequent drafts, but let's not now lose what it took a lot of effort to achieve.

				Thanks,
				-- Mike

-----Original Message-----
From: Nov Matake <matake@gmail.com> 
Sent: Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

There is no specific mechanism right now.
But future developers won’t be able to read the reason why the extension point is given only for confidential clients.



      

        
On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Are you aware of any suitable mechanism? I’m asking since from my perspective this clause is mainly intended to allow existing OpenID Connect deployments to use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I think we should not encourage others to invent their own OAuth security mechanisms. 



        

          
On 14. May 2020, at 09:37, Nov Matake <matake@gmail.com> wrote:

Hi,

Why not allowing public clients use "other suitable mechanisms” then?
OAuth WG can allow both type of clients do so, then OIDF will define nonce as the alternative only for confidential clients.



          

            
2020/05/14 15:56、Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>のメール:

Hi all,

I would also like to thank everybody for the substantial discussion.  

The proposed change for Section 4.1.2.1 works for me (as already stated). I’m not fully comfortable with the proposed change for Section 9.7 for the following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE instead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don’t feel comfortable with recommending any mechanism that this WG is not responsible for and thus did not conduct the security threat analysis for. I think the better way for us as WG is to define the extension point for other mechanisms. The OpenID Foundation (or any other body) can then fill in and issue a statement that nonce (or another suitable mechanism) fulfils the requirements of the extension point. 

Based on this considerations, I propose the following text for Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into 
the authorization response by attackers. Public clients MUST use the 
"code_challenge” with a transaction-specific value that is securely 
bound to the client and the user agent in which the transaction was 
started. Confidential clients MUST use the “code_challenge” in the 
same way or other suitable mechanisms to mitigate authorization code 
injection.

This text follows the logic in Section 4.1.2.1 and allows use of the nonce for confidential clients.

best regards,
Torsten. 



            

              
On 12. May 2020, at 02:21, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

That works for me.  Thanks all for the useful back-and-forth that got us to this point of clarity.  I suspect many of us learned things along the way; I know that I did!

                                                    Cheers,
                                                    -- Mike

From: Aaron Parecki <aaron@parecki.com>
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>; Mike Jones 
<Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also update section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into 
the authorization response by attackers. The use of the 
`code_challenge` parameter is RECOMMENDED to this end. For 
confidential clients, the OpenID Connect `nonce` parameter and ID 
Token Claim {{OpenID}} MAY be used instead of or in addition to the 
`code_challenge` parameter for this purpose. The `code_challenge` 
or OpenID Connect `nonce` value MUST be transaction-specific and 
securely bound to the client and the user agent in which the transaction was started.

This change better clarifies the specific circumstances under which the "nonce" parameter is sufficient to protect against authorization code injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.madden@forgerock.com> wrote:
I am happy with this proposed wording. Thanks for updating it.

— Neil


On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! 

We would like to propose the following text, which is a slight variation from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins with "If the client does not send the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clients, and MUST reject such requests from other clients unless there is reasonable assurance that the client mitigates authorization code injection in other ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is the clarification of which threats, and changing to MUST instead of SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we are already describing the explicit exception to the rule, it's more clear as a MUST here.

Aaron Parecki




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

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


            

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


          

          

        

        

      

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


    

    


    

  


--------------136F8E4B5EF0B4B0B3C0460E--


From nobody Mon May 18 19:55:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DBC3A07D5 for ; Mon, 18 May 2020 19:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj39Jc900CKT for ; Mon, 18 May 2020 19:55:08 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9253A07CA for ; Mon, 18 May 2020 19:55:08 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id s10so3479814pgm.0 for ; Mon, 18 May 2020 19:55:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nP/DJmJlnFlogmcZtm+GGCqmRa76b0aSVA/xi6d4jYc=; b=QGnU3B5BpQ+5S4fU3uivG1IuPUsSpbyCySHJKTFmrodxOjqi/5/g24eR2kNXIfoMX3 M0+iZD6XMK6z65XoWDz+CxTHfbBPd1N379EiyypMDLwv2cHyltRpBgk0GHojA7gAtcyJ PpLNXNDSu8+4uzba6mUon6WjB+ox/fYiDffCIx/xJCh0pF05Ln8ELXD33QIDz4B7BQKU BdkthbidwIZXPm7J9EWOfA2FaO7jvpDrfatVHFxWiTmGYuTeeM5vbMK7uk5N7XSvFhJz ofjXxEJR5zCn3zZ74wNkRi2SnTpiI93So58eCP1QSMH8u+K0yoVMKwIvySg1zlRqSBSh EUTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nP/DJmJlnFlogmcZtm+GGCqmRa76b0aSVA/xi6d4jYc=; b=oFMnxt1tta3gJ3BUgJyOOwMANISVzdqRQ6qfOhVQBz0XK9XMv0zQ3gDGFcSSEAKIbm CBJ/E8QcPah0S3pk9bjyPcjkWIqjY9OvjnnjSQFyyxO5z2iazsruekkJ0Iyuk+vZDFUO 6fvHYyE/s5MYIp0xNN2/APzDCp/a0/eDkZ+BwfNRmDmG50OgtyxIuPI1IhkiM9pGsCbL XE7sCD89dYiGkd9iKfmHwz9/9gEbDcNcyLN3qIqQhuxIRImcmBh2lZd8B9SV/BrCAsbM xA/5oyX6uJTa0UYFOF11hyiZt+6Ojqv+ZhawuCHUlZnHa3Yu7lRz4NAZR4wxIpDXOTxf 5VfA==
X-Gm-Message-State: AOAM531gGVBojcVc5CAxQlbgtOfCeALOo+8jebofAv5pgvCPNXHaNo7x uYOtsjdMKYXuPVfHVFqq0rwS4dU5ocs=
X-Google-Smtp-Source: ABdhPJzqeluOR7TMOu3VwB1LGthOKUhNpAnqGtRpFiLFhXrJM/+I5Z9ggTr1as3se9MPNe3kn9CnmQ==
X-Received: by 2002:a63:1c4c:: with SMTP id c12mr10827599pgm.26.1589856907773;  Mon, 18 May 2020 19:55:07 -0700 (PDT)
Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id n205sm8997pfd.50.2020.05.18.19.55.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2020 19:55:06 -0700 (PDT)
From: Nov Matake 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D64D77BB-819B-4806-B411-73BE4DD9A4A7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 19 May 2020 11:55:03 +0900
In-Reply-To: <1bc5387b-d9a1-fa36-83d8-15756e9a1a51@danielfett.de>
Cc: "oauth@ietf.org" 
To: Daniel Fett 
References:  <1bc5387b-d9a1-fa36-83d8-15756e9a1a51@danielfett.de>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 02:55:12 -0000

--Apple-Mail=_D64D77BB-819B-4806-B411-73BE4DD9A4A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

I thought the server MUST reject such token requests, but I couldn=E2=80=99=
t find such definition in RFC7636...

> The client will send the code, along with a (now not matching) =
code_verifier to the server. The server will ignore the code_verifier =
(as it was not expected) and send back an access token and ID token to =
the client.
=
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkc=
e-sidestep-attack =


If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2=80=
=9D would be possible.

Plus, with such AS behavior, CSRF protection using PKCE can also be =
bypassed as below.
1. The attacker removes code_challenge from his/her own AuthZ Req, =
receives a non-code_challenge-bound code, and sends it to the victim.
2. The client receives the attacker=E2=80=99s code from the victim, and =
sends it to the AS w/ the valid code_verifier bound to the victim=E2=80=99=
s browser session.
3. The AS ignores the code_verifier and returns tokens.

If that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can be =
weaker than expected..

nov

> 2020/05/19 1:54=E3=80=81Daniel Fett =E3=81=AE=E3=83=A1=
=E3=83=BC=E3=83=AB:
>=20
> Hi all,
>=20
> Talking to Torsten, we realized that providing a generic extension =
point here is probably not a good idea. It is really hard to tell what =
protects you from code injection and what does not, and people might =
come up with all sorts of non-standard and potentially insecure =
solutions.=20
>=20
> Even just for PKCE vs. Nonce, it is not obvious if they provide the =
same level of protection. In an attempt to answer this question, I tried =
to come up with a more systematic analysis of "PKCE vs Nonce". I wrote =
up my results here:=20
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ =

>=20
> Although this is not a formal analysis, I hope that I have covered all =
interesting cases. Please review the text and let me know if I have =
missed something or if there are any mistakes.
>=20
> The main results are:
> In terms of protection against CSRF and code misuse, PKCE and Nonce =
provide similar levels of security, with a slight advantage for PKCE.
> In practice, a circumvention of both mechanisms, however, is possible =
if an AS allows a client to choose between PKCE and Nonce and the client =
makes use of this freedom. I propose to call this attack the Nonce/PKCE =
Sidestep Attack. =E2=86=92 Please review the attack description in the =
analysis.
> To avoid the Nonce/PKCE Sidestep Attack, clients must not switch =
between using only PKCE and only Nonce (but may use both in parallel, or =
switch between using only PKCE and PKCE+Nonce). Authorization servers =
must enforce PKCE unless they know that the client uses Nonce for all of =
its flows (and checks the Nonce value). The presence of a nonce =
parameter in the authorization request is not sufficient to determine if =
a client actually checks the nonce claim in the ID token.
> As you can see, already having two more-or-less well-understood =
mechanisms is hard enough to wrap your head around from a security =
standpoint. We should therefore make PKCE the default and Nonce an =
option for backwards compatibility.
>=20
> To this end, I would like to propose the follwing strawman, based on =
Torsten's and Aaron's suggestions:
>=20
> An AS MUST reject requests without a code_challenge from public
> clients, and MUST reject such requests from other clients unless there
> is reasonable assurance that the client mitigates authorization code
> injection using the OpenID Connect Nonce mechanism and that this
> mitigation is used for all interactions with the client. See section
> 9.7 for details.
>=20
> Section 9.7:
>=20
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. The use of the
> `code_challenge` parameter is RECOMMENDED to this end. For
> confidential clients, the OpenID Connect `nonce` parameter and ID
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
> `code_challenge` parameter for this purpose. The `code_challenge` or
> OpenID Connect `nonce` value MUST be transaction-specific and securely
> bound to the client and the user agent in which the transaction was
> started.
>=20
> If the OpenID Connect `nonce` is used to mitigate authorization code
> injection instead of `code_challenge`, client and authorization server
> MUST ensure that the mitigation is applied to every interaction with
> the client and that the client cannot switch between `code_challenge`
> and `nonce`. For example, the presence of a `nonce` parameter in the
> authorization request is not sufficient to determine that the
> `code_verifier` check can be skipped.
>=20
>=20
> Of course, we need to adapt the wording in the Security BCP =
accordingly.
>=20
> -Daniel
>=20
>=20
>=20
>=20
> Am 15.05.20 um 01:01 schrieb Mike Jones:
>> I agree with Nov that obscuring the language in 9.7 would be a =
disservice to developers.
>>=20
>> The Security BCP, which has already going the WGLC, explicitly calls =
out the use of nonce as part of the best practices.  OAuth 2.1 should do =
no less.
>>=20
>> The 9.7 language that Aaron proposed was the result of many people's =
contributions and a vigorous discussion.  Let's publish the next version =
of 2.1 with that language intact, as I believe it represents at least a =
local point of hard-won consensus.  Let's get that language into the =
record of drafts.
>>=20
>> There's always time to debate it and change it later in subsequent =
drafts, but let's not now lose what it took a lot of effort to achieve.
>>=20
>> 				Thanks,
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: Nov Matake  =20
>> Sent: Thursday, May 14, 2020 3:18 AM
>> To: Torsten Lodderstedt  =

>> Cc: OAuth WG  ; Mike Jones =
 
>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>=20
>> There is no specific mechanism right now.
>> But future developers won=E2=80=99t be able to read the reason why =
the extension point is given only for confidential clients.
>>=20
>>> On May 14, 2020, at 18:32, Torsten Lodderstedt =
  wrote:
>>>=20
>>> Are you aware of any suitable mechanism? I=E2=80=99m asking since =
from my perspective this clause is mainly intended to allow existing =
OpenID Connect deployments to use nonce instead of PKCE in combination =
with OAuth 2.1. It=E2=80=99s a compromise. I think we should not =
encourage others to invent their own OAuth security mechanisms.=20
>>>=20
>>>> On 14. May 2020, at 09:37, Nov Matake  =
 wrote:
>>>>=20
>>>> Hi,
>>>>=20
>>>> Why not allowing public clients use "other suitable mechanisms=E2=80=9D=
 then?
>>>> OAuth WG can allow both type of clients do so, then OIDF will =
define nonce as the alternative only for confidential clients.
>>>>=20
>>>>> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =
 =
=E3=81=AE=E3=83=A1=E3=83=
=BC=E3=83=AB:
>>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> I would also like to thank everybody for the substantial =
discussion. =20
>>>>>=20
>>>>> The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:
>>>>>=20
>>>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use =
of PKCE instead of requiring it (with a well-defined exception).
>>>>> - Given the latest findings re nonce I don=E2=80=99t feel =
comfortable with recommending any mechanism that this WG is not =
responsible for and thus did not conduct the security threat analysis =
for. I think the better way for us as WG is to define the extension =
point for other mechanisms. The OpenID Foundation (or any other body) =
can then fill in and issue a statement that nonce (or another suitable =
mechanism) fulfils the requirements of the extension point.=20
>>>>>=20
>>>>> Based on this considerations, I propose the following text for =
Section 9.7:
>>>>>=20
>>>>> Clients MUST prevent injection (replay) of authorization codes =
into=20
>>>>> the authorization response by attackers. Public clients MUST use =
the=20
>>>>> "code_challenge=E2=80=9D with a transaction-specific value that is =
securely=20
>>>>> bound to the client and the user agent in which the transaction =
was=20
>>>>> started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=
=80=9D in the=20
>>>>> same way or other suitable mechanisms to mitigate authorization =
code=20
>>>>> injection.
>>>>>=20
>>>>> This text follows the logic in Section 4.1.2.1 and allows use of =
the nonce for confidential clients.
>>>>>=20
>>>>> best regards,
>>>>> Torsten.=20
>>>>>=20
>>>>>> On 12. May 2020, at 02:21, Mike Jones =
 =
 wrote:
>>>>>>=20
>>>>>> That works for me.  Thanks all for the useful back-and-forth that =
got us to this point of clarity.  I suspect many of us learned things =
along the way; I know that I did!
>>>>>>=20
>>>>>>                                                     Cheers,
>>>>>>                                                     -- Mike
>>>>>>=20
>>>>>> From: Aaron Parecki  =

>>>>>> Sent: Monday, May 11, 2020 4:55 PM
>>>>>> To: OAuth WG  
>>>>>> Cc: Neil Madden  =
; Mike Jones=20
>>>>>>  =

>>>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>>>>=20
>>>>>> Thank you Neil.
>>>>>>=20
>>>>>> To address Mike's concerns in the previous threads, I would like =
to also update section 9.7 with the following text:
>>>>>>=20
>>>>>> Clients MUST prevent injection (replay) of authorization codes =
into=20
>>>>>> the authorization response by attackers. The use of the=20
>>>>>> `code_challenge` parameter is RECOMMENDED to this end. For=20
>>>>>> confidential clients, the OpenID Connect `nonce` parameter and ID=20=

>>>>>> Token Claim {{OpenID}} MAY be used instead of or in addition to =
the=20
>>>>>> `code_challenge` parameter for this purpose. The `code_challenge`=20=

>>>>>> or OpenID Connect `nonce` value MUST be transaction-specific and=20=

>>>>>> securely bound to the client and the user agent in which the =
transaction was started.
>>>>>>=20
>>>>>> This change better clarifies the specific circumstances under =
which the "nonce" parameter is sufficient to protect against =
authorization code injection.
>>>>>>=20
>>>>>> Aaron Parecki
>>>>>>=20
>>>>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden =
  wrote:
>>>>>> I am happy with this proposed wording. Thanks for updating it.
>>>>>>=20
>>>>>> =E2=80=94 Neil
>>>>>>=20
>>>>>>=20
>>>>>> On 11 May 2020, at 19:52, Aaron Parecki  =
 wrote:
>>>>>>=20
>>>>>> Thanks for the lively discussion around PKCE in OAuth 2.1 =
everyone!=20
>>>>>>=20
>>>>>> We would like to propose the following text, which is a slight =
variation from the text Neil proposed. This would replace the paragraph =
in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1 =
)=
 that begins with "If the client does not send the "code_challenge" in =
the request..."
>>>>>>=20
>>>>>> "An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways. See section 9.7 for details."
>>>>>>=20
>>>>>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>>>>>=20
>>>>>> As Neil described, we believe this will allow ASs to support both =
OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is =
the clarification of which threats, and changing to MUST instead of =
SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we =
are already describing the explicit exception to the rule, it's more =
clear as a MUST here.
>>>>>>=20
>>>>>> Aaron Parecki
>>>>>>=20
>>>>>>=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 =

>> _______________________________________________
>> 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=_D64D77BB-819B-4806-B411-73BE4DD9A4A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi,

I thought the server MUST reject such token requests, but I =
couldn=E2=80=99t find such definition in RFC7636...

> The client will send the code, along with a (now =
not matching) code_verifier to the server. The server will ignore the =
code_verifier (as it was not expected) and send back an access token and =
ID token to the client.
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-no=
t/#noncepkce-sidestep-attack

If the behavior is =
acceptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2=80=9D would be =
possible.

Plus, with such AS behavior, CSRF =
protection using PKCE can also be bypassed as below.
1. The attacker removes code_challenge from his/her own AuthZ =
Req, receives a non-code_challenge-bound code, and sends it to =
the victim.
2. The client receives the attacker=E2=80=
=99s code from the victim, and sends it to the AS w/ the valid =
code_verifier bound to the victim=E2=80=99s browser session.
3. The AS ignores the code_verifier and returns =
tokens.

If =
that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can be =
weaker than expected..

nov

2020/05/19 1:54=E3=80=81Daniel =
Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:=



 =20
    
 =20
  

    
Hi all,

    


    

    
Talking to Torsten, we realized that
      providing a generic extension point here is probably not a good
      idea. It is really hard to tell what protects you from code
      injection and what does not, and people might come up with all
      sorts of non-standard and potentially insecure solutions. 

    

    


    

    
Even just for PKCE vs. Nonce, it is =
not
      obvious if they provide the same level of protection. In an
      attempt to answer this question, I tried to come up with a more
      systematic analysis of "PKCE vs Nonce". I wrote up my results
      here: 

    

    
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

    

    

    Although this is not a formal analysis, I hope that I have covered
    all interesting cases. Please review the text and let me know if I
    have missed something or if there are any mistakes.

    

    The main results are:

    
    
      
  1. In terms of protection against CSRF and code =
misuse, PKCE and
        Nonce provide similar levels of security, with a slight
        advantage for PKCE.
    2. 
      
  2. In practice, a circumvention of both mechanisms, =
however, is
        possible if an AS allows a client to choose between PKCE and
        Nonce and the client makes use of this freedom. I propose to
        call this attack the Nonce/PKCE Sidestep Attack. =E2=86=92 =
Please review
        the attack description in the analysis.
    3. 
      
  3. To avoid the Nonce/PKCE Sidestep Attack, clients =
must not
        switch between using only PKCE and only Nonce (but may use both
        in parallel, or switch between using only PKCE and PKCE+Nonce).
        Authorization servers must enforce PKCE unless they know that
        the client uses Nonce for all of its flows (and checks the Nonce
        value). The presence of a nonce parameter in the authorization
        request is not sufficient to determine if a client actually
        checks the nonce claim in the ID token.
    4. 
    
As you can see, already having two more-or-less =
well-understood
      mechanisms is hard enough to wrap your head around from a security
      standpoint. We should therefore make PKCE the default and Nonce an
      option for backwards compatibility.

    
To this end, I would like to propose the follwing =
strawman, based
      on Torsten's and Aaron's suggestions:

    An AS MUST reject requests without a code_challenge =
from public

    clients, and MUST reject such requests from =
other clients
      unless there

    is reasonable assurance that the client =
mitigates
      authorization code

    injection using the OpenID Connect Nonce =
mechanism and that
      this

    mitigation is used for all interactions with the =
client.
      See section

    9.7 for details.

    

    Section 9.7:

    

    Clients MUST prevent injection (replay) of =
authorization codes
      into

    the authorization response by attackers. The use =
of the

    `code_challenge` parameter is RECOMMENDED to =
this end. For

    confidential clients, the OpenID Connect `nonce` =
parameter
      and ID

    Token Claim {{OpenID}} MAY be used instead of or =
in
      addition to the

    `code_challenge` parameter for this purpose. The
      `code_challenge` or

    OpenID Connect `nonce` value MUST be =
transaction-specific
      and securely

    bound to the client and the user agent in which =
the
      transaction was

    started.

    

    If the OpenID Connect `nonce` is used to =
mitigate
      authorization code

    injection instead of `code_challenge`, client =
and
      authorization server

    MUST ensure that the mitigation is applied to =
every
      interaction with

    the client and that the client cannot switch =
between
      `code_challenge`

    and `nonce`. For example, the presence of a =
`nonce`
      parameter in the

    authorization request is not sufficient to =
determine that
      the

    `code_verifier` check can be skipped.


    
Of course, we need to adapt the wording in the =
Security BCP
      accordingly.
-Daniel

    


    

    


    

    
Am 15.05.20 um 01:01 schrieb Mike
      Jones:

    

    

      
I agree with Nov that =
obscuring the language in 9.7 would be a disservice to developers.

The Security BCP, which has already going the WGLC, explicitly calls out =
the use of nonce as part of the best practices.  OAuth 2.1 should do no =
less.

The 9.7 language that Aaron proposed was the result of many people's =
contributions and a vigorous discussion.  Let's publish the next version =
of 2.1 with that language intact, as I believe it represents at least a =
local point of hard-won consensus.  Let's get that language into the =
record of drafts.

There's always time to debate it and change it later in subsequent =
drafts, but let's not now lose what it took a lot of effort to achieve.

				Thanks,
				-- Mike

-----Original Message-----
From: Nov Matake <matake@gmail.com>=20
Sent: Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.co=
m>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

There is no specific mechanism right now.
But future developers won=E2=80=99t be able to read the reason why the =
extension point is given only for confidential clients.



      

        
On May 14, 2020, at =
18:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Are you aware of any suitable mechanism? I=E2=80=99m asking since from =
my perspective this clause is mainly intended to allow existing OpenID =
Connect deployments to use nonce instead of PKCE in combination with =
OAuth 2.1. It=E2=80=99s a compromise. I think we should not encourage =
others to invent their own OAuth security mechanisms.=20



        

          
On 14. May 2020, at =
09:37, Nov Matake <matake@gmail.com> wrote:

Hi,

Why not allowing public clients use "other suitable mechanisms=E2=80=9D =
then?
OAuth WG can allow both type of clients do so, then OIDF will define =
nonce as the alternative only for confidential clients.



          

            
2020/05/14 =
15:56=E3=80=81Torsten Lodderstedt <torsten=3D4=
0lodderstedt.net@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=
:

Hi all,

I would also like to thank everybody for the substantial discussion. =20

The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of =
PKCE instead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don=E2=80=99t feel comfortable =
with recommending any mechanism that this WG is not responsible for and =
thus did not conduct the security threat analysis for. I think the =
better way for us as WG is to define the extension point for other =
mechanisms. The OpenID Foundation (or any other body) can then fill in =
and issue a statement that nonce (or another suitable mechanism) fulfils =
the requirements of the extension point.=20

Based on this considerations, I propose the following text for Section =
9.7:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. Public clients MUST use the=20
"code_challenge=E2=80=9D with a transaction-specific value that is =
securely=20
bound to the client and the user agent in which the transaction was=20
started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=9D=
 in the=20
same way or other suitable mechanisms to mitigate authorization code=20
injection.

This text follows the logic in Section 4.1.2.1 and allows use of the =
nonce for confidential clients.

best regards,
Torsten.=20



            

              
On 12. May 2020, at =
02:21, Mike Jones <Michael=
.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

That works for me.  Thanks all for the useful back-and-forth that got us =
to this point of clarity.  I suspect many of us learned things along the =
way; I know that I did!

                                                    Cheers,
                                                    -- Mike

From: Aaron Parecki <aaron@parecki.com>
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>=
;; Mike Jones=20
<Michael.Jones@microsoft.co=
m>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also =
update section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. The use of the=20
`code_challenge` parameter is RECOMMENDED to this end. For=20
confidential clients, the OpenID Connect `nonce` parameter and ID=20
Token Claim {{OpenID}} MAY be used instead of or in addition to the=20
`code_challenge` parameter for this purpose. The `code_challenge`=20
or OpenID Connect `nonce` value MUST be transaction-specific and=20
securely bound to the client and the user agent in which the transaction =
was started.

This change better clarifies the specific circumstances under which the =
"nonce" parameter is sufficient to protect against authorization code =
injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.madden@forgerock.com>=
; wrote:
I am happy with this proposed wording. Thanks for updating it.

=E2=80=94 Neil


On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20

We would like to propose the following text, which is a slight variation =
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1=
.2.1) that begins with "If the client does not send the =
"code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth =
2.0 and 2.1 clients simultaneously. The change from Neil's text is the =
clarification of which threats, and changing to MUST instead of SHOULD. =
The "MUST...unless" is more specific than "SHOULD", and since we are =
already describing the explicit exception to the rule, it's more clear =
as a MUST here.

Aaron Parecki




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

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


            

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


          

          

        

        

      

      
_______________________________________________
OAuth mailing 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=_D64D77BB-819B-4806-B411-73BE4DD9A4A7--


From nobody Mon May 18 23:24:21 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A01C3A1239 for ; Mon, 18 May 2020 23:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfWx4nwvA9sn for ; Mon, 18 May 2020 23:24:16 -0700 (PDT)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154313A123A for ; Mon, 18 May 2020 23:24:16 -0700 (PDT)
Received: by mail-vs1-xe2f.google.com with SMTP id w65so4491582vsw.11 for ; Mon, 18 May 2020 23:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GeGL56/haCVGyj5HcjBTDHYEGZFdVxyCkyUG2n37RoY=; b=2xZvZe3LACvaeLNriFxjbJ6oPHLR8U3iA2PxM17O8VjLKVd4EUENjwaELjRJC8d7R/ K0i0k+EWZs7V4Ay3Ns05H0lGv0eQmbILYjRpKOtbeDRV8psL2rqZJhdf97x9AzMjYiG+ qz3MUC1CeJM9EUmqcnp21Ih5Rx/iQ97VuH5tzUpnC457ljbNEEixiq/7nrF/TKCSjRQC Zi84BGb4dBLXSyrL1K7SfwGQn+CaTxyUTQea5PIIIKW3CPScI2MvW47wYnF3eWMSsaWJ mm6CEbUX6/UiRjHKp1tMq5cMPgO33ZBBtoOckLMLbcPZQBODon6zAKck2Dv1KdFFGVLk /lRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GeGL56/haCVGyj5HcjBTDHYEGZFdVxyCkyUG2n37RoY=; b=g9i6gqromNE3GDLvZMKdbtciHzYMr7vT1M+SfUK+AuOZ7fZtUD+YyJGsAcIsO/8gb3 26+XLLdunv3SbFTPMUYDQDG/v2xBeL8USSrVe6i0/F/xHVGkL5ZVIluJfYPRumoV1ybw HGMbqS758KBiBgi+iHXrU0amKaBP4W4W9bq3EuxEHPMk8e7IUvGV27wDEZsdTMEpK1kL L11kmgJr+rWCMPlVj23h4HdUwzGsEiMk7HlvavEiM4ZqJF0VnUz/dEYsnrfW9BxaGBhm tLvCT7Nk8YqscK42e2IxdlQAN6+fuwzT8PLiWz6Sq4d1dNNV4W3igtSKdGcqD50CFClw 75cQ==
X-Gm-Message-State: AOAM530yMSJop44exTLkxCwHT4/79d9H9KugNuE/tidp/EPyLhI00s5b kozw76m4Vd/MOAPrSdc4GhmpBSiGadDhIrfpIeaKzw==
X-Google-Smtp-Source: ABdhPJzuTbZfglCFYjU1pBXewk9Nfjtq8HQSTwh+RyUZ7osGYo084RJ7cj3XdkU6Jz6210+p52JBSU+RsAtlx31irHM=
X-Received: by 2002:a67:3393:: with SMTP id z141mr3156921vsz.25.1589869454805;  Mon, 18 May 2020 23:24:14 -0700 (PDT)
MIME-Version: 1.0
References:  <1bc5387b-d9a1-fa36-83d8-15756e9a1a51@danielfett.de> 
In-Reply-To: 
From: Torsten Lodderstedt 
Date: Tue, 19 May 2020 08:24:03 +0200
Message-ID: 
To: Nov Matake 
Cc: Daniel Fett , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000017de6505a5fa54f7"
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 06:24:20 -0000

--00000000000017de6505a5fa54f7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

it=E2=80=99s the mixture of mechanisms that causes the issue. As already me=
ntioned
by Daniel, a client must not use different mechanism in different
transactions to prevent it. I feel we should better go with PKCE as the
only mechanism. That=E2=80=99s secure and simple.

Nov Matake  schrieb am Di. 19. Mai 2020 um 04:55:

> Hi,
>
> I thought the server MUST reject such token requests, but I couldn=E2=80=
=99t find
> such definition in RFC7636...
>
> > The client will send the code, along with a (now not matching)
> code_verifier to the server. The server will ignore the code_verifier (as
> it was not expected) and send back an access token and ID token to the
> client.
>
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepk=
ce-sidestep-attack
>
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2=
=80=9D
> would be possible.
>
> Plus, with such AS behavior, CSRF protection using PKCE can also be
> bypassed as below.
> 1. The attacker removes code_challenge from his/her own AuthZ
> Req, receives a non-code_challenge-bound code, and sends it to the victim=
.
> 2. The client receives the attacker=E2=80=99s code from the victim, and s=
ends it
> to the AS w/ the valid code_verifier bound to the victim=E2=80=99s browse=
r session.
> 3. The AS ignores the code_verifier and returns tokens.
>
> If that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can be =
weaker
> than expected..
>
> nov
>
> 2020/05/19 1:54=E3=80=81Daniel Fett =E3=81=AE=E3=83=
=A1=E3=83=BC=E3=83=AB:
>
> Hi all,
>
> Talking to Torsten, we realized that providing a generic extension point
> here is probably not a good idea. It is really hard to tell what protects
> you from code injection and what does not, and people might come up with
> all sorts of non-standard and potentially insecure solutions.
>
> Even just for PKCE vs. Nonce, it is not obvious if they provide the same
> level of protection. In an attempt to answer this question, I tried to co=
me
> up with a more systematic analysis of "PKCE vs Nonce". I wrote up my
> results here:
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>
> Although this is not a formal analysis, I hope that I have covered all
> interesting cases. Please review the text and let me know if I have misse=
d
> something or if there are any mistakes.
>
> The main results are:
>
>    1. In terms of protection against CSRF and code misuse, PKCE and Nonce
>    provide similar levels of security, with a slight advantage for PKCE.
>    2. In practice, a circumvention of both mechanisms, however, is
>    possible if an AS allows a client to choose between PKCE and Nonce and=
 the
>    client makes use of this freedom. I propose to call this attack the
>    Nonce/PKCE Sidestep Attack. =E2=86=92 Please review the attack descrip=
tion in the
>    analysis.
>    3. To avoid the Nonce/PKCE Sidestep Attack, clients must not switch
>    between using only PKCE and only Nonce (but may use both in parallel, =
or
>    switch between using only PKCE and PKCE+Nonce). Authorization servers =
must
>    enforce PKCE unless they know that the client uses Nonce for all of it=
s
>    flows (and checks the Nonce value). The presence of a nonce parameter =
in
>    the authorization request is not sufficient to determine if a client
>    actually checks the nonce claim in the ID token.
>
> As you can see, already having two more-or-less well-understood mechanism=
s
> is hard enough to wrap your head around from a security standpoint. We
> should therefore make PKCE the default and Nonce an option for backwards
> compatibility.
>
> To this end, I would like to propose the follwing strawman, based on
> Torsten's and Aaron's suggestions:
> An AS MUST reject requests without a code_challenge from public
> clients, and MUST reject such requests from other clients unless there
> is reasonable assurance that the client mitigates authorization code
> injection using the OpenID Connect Nonce mechanism and that this
> mitigation is used for all interactions with the client. See section
> 9.7 for details.
>
> Section 9.7:
>
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. The use of the
> `code_challenge` parameter is RECOMMENDED to this end. For
> confidential clients, the OpenID Connect `nonce` parameter and ID
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
> `code_challenge` parameter for this purpose. The `code_challenge` or
> OpenID Connect `nonce` value MUST be transaction-specific and securely
> bound to the client and the user agent in which the transaction was
> started.
>
> If the OpenID Connect `nonce` is used to mitigate authorization code
> injection instead of `code_challenge`, client and authorization server
> MUST ensure that the mitigation is applied to every interaction with
> the client and that the client cannot switch between `code_challenge`
> and `nonce`. For example, the presence of a `nonce` parameter in the
> authorization request is not sufficient to determine that the
> `code_verifier` check can be skipped.
>
>
> Of course, we need to adapt the wording in the Security BCP accordingly.
>
> -Daniel
>
>
>
> Am 15.05.20 um 01:01 schrieb Mike Jones:
>
> I agree with Nov that obscuring the language in 9.7 would be a disservice=
 to developers.
>
> The Security BCP, which has already going the WGLC, explicitly calls out =
the use of nonce as part of the best practices.  OAuth 2.1 should do no les=
s.
>
> The 9.7 language that Aaron proposed was the result of many people's cont=
ributions and a vigorous discussion.  Let's publish the next version of 2.1=
 with that language intact, as I believe it represents at least a local poi=
nt of hard-won consensus.  Let's get that language into the record of draft=
s.
>
> There's always time to debate it and change it later in subsequent drafts=
, but let's not now lose what it took a lot of effort to achieve.
>
> 				Thanks,
> 				-- Mike
>
> -----Original Message-----
> From: Nov Matake  
> Sent: Thursday, May 14, 2020 3:18 AM
> To: Torsten Lodderstedt  
> Cc: OAuth WG  ; Mike Jones  
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
> There is no specific mechanism right now.
> But future developers won=E2=80=99t be able to read the reason why the ex=
tension point is given only for confidential clients.
>
>
> On May 14, 2020, at 18:32, Torsten Lodderstedt  =
 wrote:
>
> Are you aware of any suitable mechanism? I=E2=80=99m asking since from my=
 perspective this clause is mainly intended to allow existing OpenID Connec=
t deployments to use nonce instead of PKCE in combination with OAuth 2.1. I=
t=E2=80=99s a compromise. I think we should not encourage others to invent =
their own OAuth security mechanisms.
>
>
> On 14. May 2020, at 09:37, Nov Matake   wrote:
>
> Hi,
>
> Why not allowing public clients use "other suitable mechanisms=E2=80=9D t=
hen?
> OAuth WG can allow both type of clients do so, then OIDF will define nonc=
e as the alternative only for confidential clients.
>
>
> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt  =E3=81=AE=E3=
=83=A1=E3=83=BC=E3=83=AB:
>
> Hi all,
>
> I would also like to thank everybody for the substantial discussion.
>
> The proposed change for Section 4.1.2.1 works for me (as already stated).=
 I=E2=80=99m not fully comfortable with the proposed change for Section 9.7=
 for the following reasons:
>
> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE=
 instead of requiring it (with a well-defined exception).
> - Given the latest findings re nonce I don=E2=80=99t feel comfortable wit=
h recommending any mechanism that this WG is not responsible for and thus d=
id not conduct the security threat analysis for. I think the better way for=
 us as WG is to define the extension point for other mechanisms. The OpenID=
 Foundation (or any other body) can then fill in and issue a statement that=
 nonce (or another suitable mechanism) fulfils the requirements of the exte=
nsion point.
>
> Based on this considerations, I propose the following text for Section 9.=
7:
>
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. Public clients MUST use the
> "code_challenge=E2=80=9D with a transaction-specific value that is secure=
ly
> bound to the client and the user agent in which the transaction was
> started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=
=9D in the
> same way or other suitable mechanisms to mitigate authorization code
> injection.
>
> This text follows the logic in Section 4.1.2.1 and allows use of the nonc=
e for confidential clients.
>
> best regards,
> Torsten.
>
>
> On 12. May 2020, at 02:21, Mike Jones   wrote:
>
> That works for me.  Thanks all for the useful back-and-forth that got us =
to this point of clarity.  I suspect many of us learned things along the wa=
y; I know that I did!
>
>                                                     Cheers,
>                                                     -- Mike
>
> From: Aaron Parecki  
> Sent: Monday, May 11, 2020 4:55 PM
> To: OAuth WG  
> Cc: Neil Madden  ; =
Mike Jones  
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
> Thank you Neil.
>
> To address Mike's concerns in the previous threads, I would like to also =
update section 9.7 with the following text:
>
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. The use of the
> `code_challenge` parameter is RECOMMENDED to this end. For
> confidential clients, the OpenID Connect `nonce` parameter and ID
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
> `code_challenge` parameter for this purpose. The `code_challenge`
> or OpenID Connect `nonce` value MUST be transaction-specific and
> securely bound to the client and the user agent in which the transaction =
was started.
>
> This change better clarifies the specific circumstances under which the "=
nonce" parameter is sufficient to protect against authorization code inject=
ion.
>
> Aaron Parecki
>
> On Mon, May 11, 2020 at 11:55 AM Neil Madden  =
 wrote:
> I am happy with this proposed wording. Thanks for updating it.
>
> =E2=80=94 Neil
>
>
> On 11 May 2020, at 19:52, Aaron Parecki  
>
>  wrote:
>
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
>
> We would like to propose the following text, which is a slight variation =
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (h=
ttps://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1..2.1 ) tha=
t begins with "If the client does not send the "code_challenge" in the requ=
est..."
>
> "An AS MUST reject requests without a code_challenge from public clients,=
 and MUST reject such requests from other clients unless there is reasonabl=
e assurance that the client mitigates authorization code injection in other=
 ways. See section 9.7 for details."
>
> Section 9.7 is where the nuances of PKCE vs nonce are described.
>
> As Neil described, we believe this will allow ASs to support both OAuth 2=
.0 and 2.1 clients simultaneously. The change from Neil's text is the clari=
fication of which threats, and changing to MUST instead of SHOULD. The "MUS=
T...unless" is more specific than "SHOULD", and since we are already descri=
bing the explicit exception to the rule, it's more clear as a MUST here.
>
> Aaron Parecki
>
>
>
>
> _______________________________________________
> OAuth mailing list
>
> OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000017de6505a5fa54f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


it=E2=80=99s the mixture of mechanisms that causes t=
he issue. As already mentioned by Daniel, a client must not use different m=
echanism in different transactions to prevent it. I feel we should better g=
o with PKCE as the only mechanism. That=E2=80=99s secure and simple.
<=
/div>

Nov Matake <matake@gmail.com=
> schrieb am Di. 19. Mai 2020 um 04:55:
Hi=
,

I thought the server MUST reject such token reque=
sts, but I couldn=E2=80=99t find such definition in RFC7636...
>=C2=A0The client will send the code, along with a (no=
w not matching) code_verifier to the server. The server will ignore the cod=
e_verifier (as it was not expected) and send back an access token and ID to=
ken to the client.

If the behavior is acce=
ptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2=80=9D would be possi=
ble.

Plus, with such AS behavior,=
 CSRF protection using PKCE can also be bypassed as below.
1. The=
 attacker removes code_challenge from his/her own AuthZ Req,=C2=A0receives=
=C2=A0a non-code_challenge-bound code, and sends it to the victim.
2. The client receives the attacker=E2=80=99s code from the victim, and s=
ends it to the AS w/ the valid code_verifier bound to the victim=E2=80=99s =
browser session.
3. The AS ignores the code_verifier and returns =
tokens.

If that=E2=80=99s the case, current OAuth =
2.0 PKCE implementation can be weaker than expected..

<=
div>nov

2020/05/19 1:54=
=E3=80=81Daniel Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
=


 =20
   =20
 =20
  

    
Hi all,

    


    

    
Talking to Torsten, we realized that
      providing a generic extension point here is probably not a good
      idea. It is really hard to tell what protects you from code
      injection and what does not, and people might come up with all
      sorts of non-standard and potentially insecure solutions. 

    

    


    

    
Even just for PKCE vs. Nonce, it is not
      obvious if they provide the same level of protection. In an
      attempt to answer this question, I tried to come up with a more
      systematic analysis of "PKCE vs Nonce". I wrote up my resul=
ts
      here: 

    

    
    

    Although this is not a formal analysis, I hope that I have covered
    all interesting cases. Please review the text and let me know if I
    have missed something or if there are any mistakes.

    

    The main results are:

    
    
      
  1. In terms of protection against CSRF and code misuse, PKCE and
        Nonce provide similar levels of security, with a slight
        advantage for PKCE.
    2. 
      
  2. In practice, a circumvention of both mechanisms, however, is
        possible if an AS allows a client to choose between PKCE and
        Nonce and the client makes use of this freedom. I propose to
        call this attack the Nonce/PKCE Sidestep Attack. =E2=86=92 Please r=
eview
        the attack description in the analysis.
    3. 
      
  3. To avoid the Nonce/PKCE Sidestep Attack, clients must not
        switch between using only PKCE and only Nonce (but may use both
        in parallel, or switch between using only PKCE and PKCE+Nonce).
        Authorization servers must enforce PKCE unless they know that
        the client uses Nonce for all of its flows (and checks the Nonce
        value). The presence of a nonce parameter in the authorization
        request is not sufficient to determine if a client actually
        checks the nonce claim in the ID token.
    4. 
    
As you can see, already having two more-or-less well-understood
      mechanisms is hard enough to wrap your head around from a security
      standpoint. We should therefore make PKCE the default and Nonce an
      option for backwards compatibility.

    
To this end, I would like to propose the follwing strawman, base=
d
      on Torsten's and Aaron's suggestions:

    An AS MUST reject requests without a code_challenge from public

    clients, and MUST reject such requests from other clients
      unless there

    is reasonable assurance that the client mitigates
      authorization code

    injection using the OpenID Connect Nonce mechanism and that
      this

    mitigation is used for all interactions with the client.
      See section

    9.7 for details.

    

    Section 9.7:

    

    Clients MUST prevent injection (replay) of authorization codes
      into

    the authorization response by attackers. The use of the

    `code_challenge` parameter is RECOMMENDED to this end. For

    confidential clients, the OpenID Connect `nonce` parameter
      and ID

    Token Claim {{OpenID}} MAY be used instead of or in
      addition to the

    `code_challenge` parameter for this purpose. The
      `code_challenge` or

    OpenID Connect `nonce` value MUST be transaction-specific
      and securely

    bound to the client and the user agent in which the
      transaction was

    started.

    

    If the OpenID Connect `nonce` is used to mitigate
      authorization code

    injection instead of `code_challenge`, client and
      authorization server

    MUST ensure that the mitigation is applied to every
      interaction with

    the client and that the client cannot switch between
      `code_challenge`

    and `nonce`. For example, the presence of a `nonce`
      parameter in the

    authorization request is not sufficient to determine that
      the

    `code_verifier` check can be skipped.


    
Of course, we need to adapt the wording in the Security BCP
      accordingly.
-Daniel

    


    

    


    

    
Am 15.05.20 um 01:01 schrieb Mike
      Jones:

    

    
=


      
I agree with Nov that obscuring the language in 9.7 would be a d=
isservice to developers.

The Security BCP, which has already going the WGLC, explicitly calls out th=
e use of nonce as part of the best practices.  OAuth 2.1 should do no less.

The 9.7 language that Aaron proposed was the result of many people's co=
ntributions and a vigorous discussion.  Let's publish the next version =
of 2.1 with that language intact, as I believe it represents at least a loc=
al point of hard-won consensus.  Let's get that language into the recor=
d of drafts.

There's always time to debate it and change it later in subsequent draf=
ts, but let's not now lose what it took a lot of effort to achieve.

				Thanks,
				-- Mike

-----Original Message-----
From: Nov Matake <=
matake@gmail.com>=20
Sent: Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@=
ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

There is no specific mechanism right now.
But future developers won=E2=80=99t be able to read the reason why the exte=
nsion point is given only for confidential clients.



      
<=
div style=3D"word-wrap:break-word;line-break:after-white-space">
<=
div>
There is=
 no specific mechanism right now.

But future developers won=E2=80=99t be able to read the reason why the exte=
nsion point is given only for confidential clients.

This is not a compelling argument.

The current situation is that we know of a handful of threats and att=
acks, we know that PKCE solves them for both confidential and public client=
s, and we also believe that OpenID Connect has solved one of the threats fo=
r confidential clients a different way. The reason this conversation is hap=
pening at all is because we want to make sure that OpenID Connect can conti=
nue=C2=A0to solve that problem its own way outside of OAuth without conflic=
ting with OAuth.

It's not useful to anyone to =
leave extension points open for hypothetical solutions later when we alread=
y know of a solution that works for public clients. At that point that shou=
ld just be a new spec.

Aaron Parecki


On Thu, May 14, 2020 at 3:18 AM Nov Matake <matake@gmail.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">There is no specific mecha=
nism right now.

But future developers won=E2=80=99t be able to read the reason why the exte=
nsion point is given only for confidential clients.



> On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> w=
rote:

> 

> Are you aware of any suitable mechanism? I=E2=80=99m asking since from=
 my perspective this clause is mainly intended to allow existing OpenID Con=
nect deployments to use nonce instead of PKCE in combination with OAuth 2.1=
. It=E2=80=99s a compromise. I think we should not encourage others to inve=
nt their own OAuth security mechanisms. 

> 





--000000000000c46c1e05a5a428d3--


From nobody Thu May 14 17:12:29 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5603A07AD for ; Thu, 14 May 2020 17:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZjEE0ZX6URQ for ; Thu, 14 May 2020 17:12:24 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3011E3A079A for ; Thu, 14 May 2020 17:12:24 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id w65so110596pfc.12 for ; Thu, 14 May 2020 17:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ITVyk1/CbzY9sRdXKGtuE/TLR74VQ3S+3pDaHzFnEAY=; b=sTFmI/sTif1PxEVkbq/kpFB1cKuOo6TdNau1VrTbHpDE3Uw9XpcTQ61wPctwQ440Yl QfplZ0g4NBpKSZ8az3lM8prDyZhP4NxRopsiaa0lT5JyDzBTu42I3srRXFaZjb2FzYLF Hsuufld5SIfusU//1AsUfSrXKoXHiR4hnB0PA5aAKkHKj8bL4FzGnts2LsucloSmvRhL kNHLcFAZNPQ7mWHuMUpotOOeljGKKkLPklKDSNlndsmmGIlFvId9ZvYMxJ/L5tu5oiCi JGU/hW1VP1de9TyhQr3gYPRDjHZ+/zj4LtO8ae1qh4gqetygwPsxKLY2S08EPIvE3cjX lJJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ITVyk1/CbzY9sRdXKGtuE/TLR74VQ3S+3pDaHzFnEAY=; b=LHzf/AGYKqYRyyoB1Upw/XJLassdHfA2rxeX71ryzhyjV1CdBExgLovzR3dRTivZ07 zSRsUWQ4uuDZ3yGPpaY7wzr2THc2t43FPpt0mzp0yywGcHTHS9iluEIO//IGtrMpoGNf 2vYuaX1GPh7IBkQjVvYRZlDbDU2+aFg95XnEIF6IlfkHpir+6pFtHgSMzgwaXJI3nyXg 0/MnAsyUc35fwwNyW6xBBeNGXbd/bJy7NR5KTBD3yVxfoCyKacc1NJisC8Yvk/3Yn2iw BzCmYiztAbZuS5zrjVFbISy5thrO3480z/QuzjQZNPKbx0nn5thB+Rx9V39glhJIG6RB IgqA==
X-Gm-Message-State: AOAM533EM+mZQQ3nHWvnayNcXiiuz5nFFvp21mHmlJxNxH6Ttq6qsRBj 4f9XyJOLRFvKjmWDiQuqRPSxxZaCDnna5w==
X-Google-Smtp-Source: ABdhPJwnQbzkbzkfvvkglg4Fa/s6a39QRgqaKoQWLoNPyMD6aqgM5hMNzD9EhXR3EPuV9zB+aj2CXA==
X-Received: by 2002:a63:155f:: with SMTP id 31mr667560pgv.0.1589501543055; Thu, 14 May 2020 17:12:23 -0700 (PDT)
Received: from [172.16.80.56] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id q25sm307999pfh.94.2020.05.14.17.12.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 May 2020 17:12:22 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-519DDF2A-8705-43F6-93BE-B8AC6ADF4427
Content-Transfer-Encoding: 7bit
From: Nov Matake 
Mime-Version: 1.0 (1.0)
Date: Fri, 15 May 2020 09:12:20 +0900
Message-Id: <8A81492B-F950-4018-8AC1-849047023534@gmail.com>
References: 
Cc: Torsten Lodderstedt , OAuth WG 
In-Reply-To: 
To: Aaron Parecki 
X-Mailer: iPad Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 00:12:27 -0000

--Apple-Mail-519DDF2A-8705-43F6-93BE-B8AC6ADF4427
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Then the sentence should not open extension points even for confidential cli=
ents,
- by mention OIDC notice explicitly
- by allowing currently existing alternatives only (and prohibit new ones)
etc.

iPad=E3=81=8B=E3=82=89=E9=80=81=E4=BF=A1

> 2020/05/15 8:36=E3=80=81Aaron Parecki =E3=81=AE=E3=83=A1=
=E3=83=BC=E3=83=AB:
>=20
> =EF=BB=BF
>> There is no specific mechanism right now.
>> But future developers won=E2=80=99t be able to read the reason why the ex=
tension point is given only for confidential clients.
>=20
> This is not a compelling argument.
>=20
> The current situation is that we know of a handful of threats and attacks,=
 we know that PKCE solves them for both confidential and public clients, and=
 we also believe that OpenID Connect has solved one of the threats for confi=
dential clients a different way. The reason this conversation is happening a=
t all is because we want to make sure that OpenID Connect can continue to so=
lve that problem its own way outside of OAuth without conflicting with OAuth=
.
>=20
> It's not useful to anyone to leave extension points open for hypothetical s=
olutions later when we already know of a solution that works for public clie=
nts. At that point that should just be a new spec.
>=20
> Aaron Parecki
>=20
>=20
>> On Thu, May 14, 2020 at 3:18 AM Nov Matake  wrote:
>> There is no specific mechanism right now.
>> But future developers won=E2=80=99t be able to read the reason why the ex=
tension point is given only for confidential clients.
>>=20
>> > On May 14, 2020, at 18:32, Torsten Lodderstedt  wrote:
>> >=20
>> > Are you aware of any suitable mechanism? I=E2=80=99m asking since from m=
y perspective this clause is mainly intended to allow existing OpenID Connec=
t deployments to use nonce instead of PKCE in combination with OAuth 2.1. It=
=E2=80=99s a compromise. I think we should not encourage others to invent th=
eir own OAuth security mechanisms.=20
>> >=20
>>=20

--Apple-Mail-519DDF2A-8705-43F6-93BE-B8AC6ADF4427
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Then the sentence should not open exte=
nsion points even for confidential clients,
- by mention OIDC noti=
ce explicitly
- by allowing currently existing alternatives only (=
and prohibit new ones)
etc.

iPad=E3=
=81=8B=E3=82=89=E9=80=81=E4=BF=A1

2020/05/15 8:36=E3=80=81Aaron Parecki <aaron@parecki.com>=E3=
=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

=EF=BB=BF
There is no specific mechanism right now.

But future developers won=E2=80=99t be able to read the reason why the exten=
sion point is given only for confidential clients.

This is not a compelling argument.

The current situation is that we know of a handful of threats and attacks=
, we know that PKCE solves them for both confidential and public clients, an=
d we also believe that OpenID Connect has solved one of the threats for conf=
idential clients a different way. The reason this conversation is happening a=
t all is because we want to make sure that OpenID Connect can continue =
to solve that problem its own way outside of OAuth without conflicting with O=
Auth.

It's not useful to anyone to leave extension p=
oints open for hypothetical solutions later when we already know of a soluti=
on that works for public clients. At that point that should just be a new sp=
ec.

Aaron Parecki


On Thu, May 14, 2020 at 3:18 AM Nov Matake <matake@gmail.com> wrote:
There is no specific mechanism right now.

But future developers won=E2=80=99t be able to read the reason why the exten=
sion point is given only for confidential clients.



> On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> wro=
te:

> 

> Are you aware of any suitable mechanism? I=E2=80=99m asking since from m=
y perspective this clause is mainly intended to allow existing OpenID Connec=
t deployments to use nonce instead of PKCE in combination with OAuth 2.1. It=
=E2=80=99s a compromise. I think we should not encourage others to invent th=
eir own OAuth security mechanisms. 

> 





=

--Apple-Mail-519DDF2A-8705-43F6-93BE-B8AC6ADF4427--


From nobody Fri May 15 09:13:40 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CF33A0BB3 for ; Fri, 15 May 2020 09:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkqWG2O2UTzz for ; Fri, 15 May 2020 09:13:37 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09F03A0C00 for ; Fri, 15 May 2020 09:13:36 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id i68so2398634qtb.5 for ; Fri, 15 May 2020 09:13:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=/FP3JABfq287i6rqFVlg+7XoKSkLb/pO/crYGT5rogc=; b=Upq8yQYbuy/uriVGl6sFhff9rGDmyiDZWeCXjGHM1kgFTwAHV6azvYGiqYBu4GsCPk M6ACgybhy6LKCAv9gcX+mo77ZUyFP0MGSv01UkxCDA/NgVf0WbQfn4BZoVcLUw3k0jqj j5Lh+c029rcZ+cHO7fCdnKz4sl64/LuPj1clBqtIStWgzPH+RA2f0wOOLFrVPKcxfCCZ B3QQmvO4FAVnbch3XtXDK5kD25jG1DdLdy80xxJlSAxYjL7JLAyl85KRxilZVp8pOLmM MpQVJE5Bd9LJOZB1sC7bTz5vPQEkR3iWurIT1Ss8nyvPgoRt8P/ThtQRwo88TcY5vOXi wrrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/FP3JABfq287i6rqFVlg+7XoKSkLb/pO/crYGT5rogc=; b=XVw8Q7qCp/qzqlsOVKBHgcau+cwu9Fn3qF5pH0WYiaJf5XrCl4iDZYme0/6ZEcQxgG Pt03gL48SdF9OsR1UpNDyIiewMaVqXE1F47cKm9GC2EclTRsKRAU1xrCMW0RJANde8S5 5hKBHMLPgAHQQjBY4YORQqQK5ZghAtcdRaYlmnKaiZFfUD3NQco60YSGAqrLHnArBsrf pvqaurGdIpwYRGaHOKPpHm8rFaiNE6iAw1h8fdarceBM5zyqAdbKM2UpwEzeU1lfDWb5 kUlazKt/WTIeGD55pG+ZrGHuSMlFBKMu1pAXfy/xRumJksR5akYABikE01ErwpSz/GCr nvzw==
X-Gm-Message-State: AOAM531DmckViHXGUH6urROjiGE8vg04KD1EraWTjJa3ZJC/2gb5/wS2 iAP7W0K8Wa1bWx+otNUrqp81C8apgC4LupnareU=
X-Google-Smtp-Source: ABdhPJzu/Mhkb0+MQk+yy6g8Z9ClKSS7qEde/6OWdj6nn1XmKcr67P+BnEhjkHd9XjAq9KIgnBNRRKnPQ/WtILYx+jY=
X-Received: by 2002:ac8:39a4:: with SMTP id v33mr4404087qte.251.1589559215811;  Fri, 15 May 2020 09:13:35 -0700 (PDT)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Beena Santhosh 
Date: Fri, 15 May 2020 21:43:24 +0530
Message-ID: 
To: Aaron Parecki , oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000068754405a5b218d1"
Archived-At: 
Subject: Re: [OAUTH-WG] Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 16:13:39 -0000

--00000000000068754405a5b218d1
Content-Type: text/plain; charset="UTF-8"

Hi Aaron,

I had a re-look at this and the difference I still see is that I am able to
use a common client_id with Password Grant, which does not seem possible
using Credentials Grant. Without Password grant I don't see a way to
achieve this.

Thank You,
Beena


On Tue, May 12, 2020 at 12:40 PM Beena Santhosh <
beenapurushothaman@gmail.com> wrote:

> Hi Aaron,
>
>
> What we are planning to build is a Public first party client. As per the
> spec the client secret is optional for Password Grant. Hence we choose to
> use a common client_id across all the devices. The first party client on
> every device  will get the  common client_id through our proprietary API.
> We found this as a difference between Password Grant and Client credentials
> grant. We could be wrong but this is our interpretation.  This way we could
> make use of the rest of the benefits that OAuth provides around access
> tokens
>
>
> Thank You,
>
> Beena
>
> On Mon, May 11, 2020 at 11:15 PM Aaron Parecki  wrote:
>
>> With the password grant you'd then need to register 50,000+ user
>> accounts, right? How is that different from registering that many clients?
>>
>> On Mon, May 11, 2020 at 10:39 AM Beena Santhosh <
>> beenapurushothaman@gmail.com> wrote:
>>
>>> Hi Aaron,
>>>
>>> Thank You for the quick response.
>>>
>>> We do support  1, 50, 000+ devices and that means we need to register
>>> those many devices dynamically,  the provider we have evaluated  is not
>>> supporting that scale . Once we  incorporate IoT, we need to support
>>> millions of devices. With Password Grant as we need only one client_id it
>>> is easy to manage. Also our client is First Party client.
>>>
>>>
>>> Thank You,
>>>
>>> Beena
>>>
>>> On Sun, May 10, 2020 at 7:50 PM Aaron Parecki  wrote:
>>>
>>>> Hi Beena,
>>>>
>>>> This sounds like a great use of the client credentials grant. The
>>>> password grant is being removed from OAuth 2.0 by the Security Best Current
>>>> Practice. Can you clarify what you've found useful about the password grant
>>>> that the client credentials grant doesn't solve?
>>>>
>>>> Aaron Parecki
>>>>
>>>>
>>>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>>>> beenapurushothaman@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> We have a product with client server architecture where our server
>>>>> manages thousands of devices. Each device has a client-piece that talks to
>>>>> the server over SOAP/REST. The client currently uses a HTTP Basic
>>>>> Authentication (unique id and a secret string) for all the calls. The
>>>>> secret string is created when the device enrolls to the server. It is
>>>>> available at the server as well as stored securely on the device. For the
>>>>> rest calls it is the device that is getting authenticated.
>>>>>
>>>>>
>>>>>
>>>>>  Sending the credentials every time is less than ideal and we want to
>>>>> move to some tokenized device authentication. We evaluated OpendID Connect
>>>>> based on the general recommendation of SSO solution, but the issue is we do
>>>>> not have any user interaction and hence there is no Grant flow that is
>>>>> fitting. Hence we evaluated OAuth grant type of which we found Password
>>>>> Grant and Client Credentials Grant is matching our requirement.
>>>>>
>>>>>
>>>>>
>>>>>  In order to use Client Credentials in our use case, we need to do
>>>>> dynamic registration for the thousands of devices managed by the server, if
>>>>> IoT comes into picture the number is going to be even higher, which is
>>>>> highly cumbersome to manage.  Also, as per  RFC7591 on dynamic client
>>>>> registration, using access token for registering client is optional too.
>>>>> Even though the Password grant is highly discouraged by the spec, we found
>>>>> it to be highly matching with our requirements.
>>>>>
>>>>>
>>>>>
>>>>> But as per the Oauth 2.1 proposal, password grant is going to be
>>>>> removed. Can you suggest the way forward for us? I believe we are not
>>>>> a one-off case.
>>>>>
>>>>>
>>>>> Thank You,
>>>>>
>>>>> Beena
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>

--00000000000068754405a5b218d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Aaron,

I had a re-look at this and t=
he difference I still see is that I am able to use a common client_id with =
Password Grant, which does not seem possible using Credentials Grant. Witho=
ut Password grant I don't see a way to achieve=C2=A0this.
Thank You,
Beena


On Tue, May 12, 2020 at 12:40 PM Beena Santhosh <beenapurushothaman@gma=
il.com> wrote:
Hi Aaron,

<=
/span>
What we are planning to build is a Public first =
party client.
As per the spec the client secret is=C2=A0optional for Password Grant. Hence we choose to use a common
client_id across all the devices. The first party client on every device=C2=
=A0 will get
the=C2=A0 common client_id through our
proprietary API. We found this as a difference between Password Grant and
Client credentials grant. We could be wrong but this is our
interpretation.=C2=A0 This way we could make
use of the rest of the benefits that =
OAuth provides around access tokens=C2=A0

Thank You,=C2=A0
Beena=


On Mon, May 11, 2020 at 11:15 PM Aaron Parecki <aaron@parecki.com> =
wrote:
With the password grant you'd then need to register 50,000+ us=
er accounts, right? How is that different from registering that many client=
s?=C2=A0

On Mon, May 11, 2020 at 10:39 AM Beena Santhosh <beenapurushothaman@gmail=
.com> wrote:
Hi Aaron,

Thank You for the quick=
=C2=A0response.

We do support=C2=A0 1, 50, 000+ devices and that m=
eans we need to
register those many devices dynamically,=C2=A0
the provider we have evaluated=C2=A0 is
not supporting that scale . Once we=C2=A0
incorporate IoT, we need to support millions of devices. With Password
Grant as we need only one client_id it is easy to manage. Also our client i=
s
First Party client.=C2=A0

Thank You,
Beena

On Sun, May 10, 2020 at 7:50 PM Aaron Parecki <aaron@parecki.com> w=
rote:
Hi Beena,

This sounds like a great use of the c=
lient credentials grant. The password grant is being removed from OAuth 2.0=
 by the Security Best Current Practice. Can you clarify what=C2=A0you'v=
e found useful about the password grant that the client credentials grant d=
oesn't solve?=C2=A0

Aaron Parecki

On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <beenapurushothaman@gmail.=
com> wrote:
Hi,

<=
/p>
We have a pro=
duct
with client server architecture where our server manages thousands of devic=
es.
Each device has a client-piece that talks to the server over SOAP/REST. The
client currently uses a HTTP Basic Authentication (unique id and a secret
string) for all the calls. The secret string is created when the device enr=
olls
to the server. It is available at the server as well as stored securely on =
the
device. For the rest calls it is the device that is getting authenticated.<=
/p>


=C2=A0



=C2=A0Sending th=
e credentials every time is less
than ideal and we want to move to some tokenized device authentication. We
evaluated OpendID Connect based on the general recommendation of SSO soluti=
on,
but the issue is we do not have any user interaction and hence there is no
Grant flow that is fitting. Hence we evaluated OAuth grant type of which we
found Password Grant and Client Credentials Grant is matching our requireme=
nt.



=C2=A0



=C2=A0In order t=
o use Client Credentials in our use
case, we need to do dynamic registration for the thousands of devices manag=
ed
by the server, if IoT comes into picture the number is going to be even hig=
her,
which is highly cumbersome to manage.=C2=A0
Also, as per=C2=A0 RFC7591 on dynamic
client registration, using access token for registering client is optional
too.=C2=A0 Even though the Password grant is
highly discouraged by the spec, we found it to be highly matching with our
requirements.



=C2=A0



=
But as
per the Oauth 2.1 proposal, password grant is going to be removed. Can
you suggest the way forward for us? I
believe we are not a one-off case.

Thank You,<=
/span>
Beena

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












--00000000000068754405a5b218d1--


From nobody Fri May 15 10:44:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5864C3A0BD6 for ; Fri, 15 May 2020 10:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9lqP3cUVWxf for ; Fri, 15 May 2020 10:44:13 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B013A0B11 for ; Fri, 15 May 2020 10:44:12 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id f134so3146880wmf.1 for ; Fri, 15 May 2020 10:44:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J7A1zY6ebsO6Z1b8YHKaDijwvAYJk9BFnwExt1hu6cY=; b=LxK96WdBZhYK+Vx2ELz2rx8cA9fBk7FdXZJm9NGgjs7wPf9yCodtNQTTZx4fsHUHmw K/ZMxbiqSmRNsy0Te3aYJzi1TKTM9lGam4tmBdbBvFpp0fI008MQfKt6Iwy7+HjZPg11 FzpJPQJ9vEhS9NN0V715iJ9Wqco3ZBOdKtqyUAsZSahmK5ylXWwH9yQVtkbd6ffXt2+W qyObRk3TG3BVlfDCv0O55kUCND1/PgZgfLQxO7WP7OyfD2ZiOcRy8Ph8whARiMAw8DwI jZxSXArCPXaZ1CKO9WUDLFuTlPWu3dyDnp0ddQ6+TkVzVJUFxv0MxMQklkPriRG7gM9b qRmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J7A1zY6ebsO6Z1b8YHKaDijwvAYJk9BFnwExt1hu6cY=; b=R2xNP28clQG++dipfe1To/rrGVXN7gH3F4O2UdLhKh0f4TNKn96KKautCIAJtjO1h0 1Uz2kFmpu3zBleJzmXR/dCTBxwq3jiuIp6Ib3dFooIENtSjAdzkBHDL5PBfebalIAmIX 5JHuqfbqDkBktVRhWVtXwNrIn5eQqtyi10cRM1MpAZWS1/sB7uYJqjCZ2Anf78/NCDOO AhvU80omsRcyHw9+XA98GmlWmbemLI/boM4jUbNtVrHQIYJIslIrUNsXyBzzMUHQvP39 H/bA8dEmkTmN3LaYYYROiWZXQOLSqxBQcO8ce51HvSluvZwxtKuRsA9P7TX3+/YvPn/X MvZg==
X-Gm-Message-State: AOAM531/FbckJhpgqg/1yzsDRz/XQn4cFn33QIIgv7nOAL4ONjdD5z5P mfBUTk7MqvP41ZKOXBYAI3EDjJYxfVzjHjAJE8DN629K
X-Google-Smtp-Source: ABdhPJwdrEC+a8iWl5FFfWy854ehe+HBjHmWYLzV6KvVHrWlpSpTZOYb8XPvksWqDkEH0NE1+T87iQqY3cOOWWaC5Ug=
X-Received: by 2002:a7b:cc84:: with SMTP id p4mr5459477wma.159.1589564650709;  Fri, 15 May 2020 10:44:10 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Mohamed Seada 
Date: Fri, 15 May 2020 19:44:01 +0200
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005a661305a5b35c51"
Archived-At: 
Subject: Re: [OAUTH-WG] Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 17:44:16 -0000

--0000000000005a661305a5b35c51
Content-Type: text/plain; charset="UTF-8"

Hi,

If the client credential is being used by the first-party client, you can
use a generic token that could access any resource.
The need for a password grant here is to identify the resource owner with
his credentials, as this is just for first-party, you don't need his secret
just id.
I think (not in spec.) this could be achieved by adding a new optional
parameter for client credentials resource_owner_id.

Thanks,

On Fri, 15 May 2020, 6:13 pm Beena Santhosh, 
wrote:

> Hi Aaron,
>
> I had a re-look at this and the difference I still see is that I am able
> to use a common client_id with Password Grant, which does not seem possible
> using Credentials Grant. Without Password grant I don't see a way to
> achieve this.
>
> Thank You,
> Beena
>
>
> On Tue, May 12, 2020 at 12:40 PM Beena Santhosh <
> beenapurushothaman@gmail.com> wrote:
>
>> Hi Aaron,
>>
>>
>> What we are planning to build is a Public first party client. As per the
>> spec the client secret is optional for Password Grant. Hence we choose
>> to use a common client_id across all the devices. The first party client on
>> every device  will get the  common client_id through our proprietary API.
>> We found this as a difference between Password Grant and Client credentials
>> grant. We could be wrong but this is our interpretation.  This way we could
>> make use of the rest of the benefits that OAuth provides around access
>> tokens
>>
>>
>> Thank You,
>>
>> Beena
>>
>> On Mon, May 11, 2020 at 11:15 PM Aaron Parecki  wrote:
>>
>>> With the password grant you'd then need to register 50,000+ user
>>> accounts, right? How is that different from registering that many clients?
>>>
>>> On Mon, May 11, 2020 at 10:39 AM Beena Santhosh <
>>> beenapurushothaman@gmail..com > wrote:
>>>
>>>> Hi Aaron,
>>>>
>>>> Thank You for the quick response.
>>>>
>>>> We do support  1, 50, 000+ devices and that means we need to register
>>>> those many devices dynamically,  the provider we have evaluated  is not
>>>> supporting that scale . Once we  incorporate IoT, we need to support
>>>> millions of devices. With Password Grant as we need only one client_id it
>>>> is easy to manage. Also our client is First Party client.
>>>>
>>>>
>>>> Thank You,
>>>>
>>>> Beena
>>>>
>>>> On Sun, May 10, 2020 at 7:50 PM Aaron Parecki 
>>>> wrote:
>>>>
>>>>> Hi Beena,
>>>>>
>>>>> This sounds like a great use of the client credentials grant. The
>>>>> password grant is being removed from OAuth 2.0 by the Security Best Current
>>>>> Practice. Can you clarify what you've found useful about the password grant
>>>>> that the client credentials grant doesn't solve?
>>>>>
>>>>> Aaron Parecki
>>>>>
>>>>>
>>>>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>>>>> beenapurushothaman@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> We have a product with client server architecture where our server
>>>>>> manages thousands of devices. Each device has a client-piece that talks to
>>>>>> the server over SOAP/REST. The client currently uses a HTTP Basic
>>>>>> Authentication (unique id and a secret string) for all the calls. The
>>>>>> secret string is created when the device enrolls to the server. It is
>>>>>> available at the server as well as stored securely on the device. For the
>>>>>> rest calls it is the device that is getting authenticated.
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Sending the credentials every time is less than ideal and we want to
>>>>>> move to some tokenized device authentication. We evaluated OpendID Connect
>>>>>> based on the general recommendation of SSO solution, but the issue is we do
>>>>>> not have any user interaction and hence there is no Grant flow that is
>>>>>> fitting. Hence we evaluated OAuth grant type of which we found Password
>>>>>> Grant and Client Credentials Grant is matching our requirement.
>>>>>>
>>>>>>
>>>>>>
>>>>>>  In order to use Client Credentials in our use case, we need to do
>>>>>> dynamic registration for the thousands of devices managed by the server, if
>>>>>> IoT comes into picture the number is going to be even higher, which is
>>>>>> highly cumbersome to manage.  Also, as per  RFC7591 on dynamic client
>>>>>> registration, using access token for registering client is optional too.
>>>>>> Even though the Password grant is highly discouraged by the spec, we found
>>>>>> it to be highly matching with our requirements.
>>>>>>
>>>>>>
>>>>>>
>>>>>> But as per the Oauth 2.1 proposal, password grant is going to be
>>>>>> removed. Can you suggest the way forward for us? I believe we are
>>>>>> not a one-off case.
>>>>>>
>>>>>>
>>>>>> Thank You,
>>>>>>
>>>>>> Beena
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000005a661305a5b35c51
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

If the client credential=C2=A0is being used by the fi=
rst-party=C2=A0client, you can use a generic token that could access any re=
source.
The need for a password grant here is to identify the resource owner =
with his credentials, as this is just for first-party, you don't need h=
is secret just id.
I think (not in spec.) this could be achieved by adding a =
new optional parameter for client credentials=C2=A0resource_owner_id.

Thanks,
On Fri, 1=
5 May 2020, 6:13 pm Beena Santhosh, <beenapurushothaman@gmail.com> wrote:<=
br>
Hi Aaron,

=

I had a re-look at this and the difference I still see is that I=
 am able to use a common client_id with Password Grant, which does not seem=
 possible using Credentials Grant. Without Password grant I don't see a=
 way to achieve=C2=A0this.

Thank You,
Be=
ena


On Tue, May 12, 2020 at 1=
2:40 PM Beena Santhosh <beenapurushothaman@gmail.com> w=
rote:
Hi Aaron,

=

What we are planning to build is a Public first party client.
As per the spec the client secret is=C2=A0optional for Password Grant. Hence we choose to use a common
client_id across all the devices. The first party client on every device=C2=
=A0 will get
the=C2=A0 common client_id through our
proprietary API. We found this as a difference between Password Grant and
Client credentials grant. We could be wrong but this is our
interpretation.=C2=A0 This way we could make
use of the rest of the benefits that =
OAuth provides around access tokens=C2=A0

Thank You,=C2=A0
Beena=


On Mon, May 11, 2020 at 11:15 PM Aaron Parecki <aaron@p=
arecki.com> wrote:
With the password grant you'd then need to =
register 50,000+ user accounts, right? How is that different from registeri=
ng that many clients?=C2=A0

On Mon, May 11, 2020 at 10:39 AM Beena Santhosh =
<beenapurushothaman@gmail..com> wrote:
Hi Aaron,
<=
br>
Thank You for the quick=C2=A0response.

We do support=
=C2=A0 1, 50, 000+ devices and that means we need to
register those many devices dynamically,=C2=A0
the provider we have evaluated=C2=A0 is
not supporting that scale . Once we=C2=A0
incorporate IoT, we need to support millions of devices. With Password
Grant as we need only one client_id it is easy to manage. Also our client i=
s
First Party client.=C2=A0

Thank You,
Beena

On Sun, May 10, 2020 at 7:50 PM Aaron Parecki <aaron@pa=
recki.com> wrote:
Hi Beena,

This sounds like a=
 great use of the client credentials grant. The password grant is being rem=
oved from OAuth 2.0 by the Security Best Current Practice. Can you clarify =
what=C2=A0you've found useful about the password grant that the client =
credentials grant doesn't solve?=C2=A0

Aaron P=
arecki


On Sun, May 10, 2020 at 3:18 AM Beena Santhosh &=
lt;beenapurushothaman@gmail.com> wrote:
Hi,

We have a product
with client server architecture where our server manages thousands of devic=
es.
Each device has a client-piece that talks to the server over SOAP/REST. The
client currently uses a HTTP Basic Authentication (unique id and a secret
string) for all the calls. The secret string is created when the device enr=
olls
to the server. It is available at the server as well as stored securely on =
the
device. For the rest calls it is the device that is getting authenticated.<=
/p>


=C2=A0



=C2=A0Sending th=
e credentials every time is less
than ideal and we want to move to some tokenized device authentication. We
evaluated OpendID Connect based on the general recommendation of SSO soluti=
on,
but the issue is we do not have any user interaction and hence there is no
Grant flow that is fitting. Hence we evaluated OAuth grant type of which we
found Password Grant and Client Credentials Grant is matching our requireme=
nt.



=C2=A0



=C2=A0In order t=
o use Client Credentials in our use
case, we need to do dynamic registration for the thousands of devices manag=
ed
by the server, if IoT comes into picture the number is going to be even hig=
her,
which is highly cumbersome to manage.=C2=A0
Also, as per=C2=A0 RFC7591 on dynamic
client registration, using access token for registering client is optional
too.=C2=A0 Even though the Password grant is
highly discouraged by the spec, we found it to be highly matching with our
requirements.



=C2=A0



=
But as
per the Oauth 2.1 proposal, password grant is going to be removed. Can
you suggest the way forward for us? I
believe we are not a one-off case.

Thank You,<=
/span>
Beena

_______________________________________________

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




<=
blockquote type=3D"cite">

        
On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net&g=
t; wrote:

Are you aware of any suitable mechanism? I=E2=80=99m asking since from my p=
erspective this clause is mainly intended to allow existing OpenID Connect =
deployments to use nonce instead of PKCE in combination with OAuth 2.1. It=
=E2=80=99s a compromise. I think we should not encourage others to invent t=
heir own OAuth security mechanisms.=20



        

          
On 14. May 2020, at 09:37, Nov Matake <matake@gmail.com> wrote:

Hi,

Why not allowing public clients use "other suitable mechanisms=E2=80=
=9D then?
OAuth WG can allow both type of clients do so, then OIDF will define nonce =
as the alternative only for confidential clients.



          
<=
/div>
=


            
2020/05/14 15:56=E3=80=81Torsten Lodderstedt <tors=
ten=3D40lodderstedt.net@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=
=E3=83=AB:

Hi all,

I would also like to thank everybody for the substantial discussion. =20

The proposed change for Section 4.1.2.1 works for me (as already stated). I=
=E2=80=99m not fully comfortable with the proposed change for Section 9.7 f=
or the following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE i=
nstead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don=E2=80=99t feel comfortable with =
recommending any mechanism that this WG is not responsible for and thus did=
 not conduct the security threat analysis for. I think the better way for u=
s as WG is to define the extension point for other mechanisms. The OpenID F=
oundation (or any other body) can then fill in and issue a statement that n=
once (or another suitable mechanism) fulfils the requirements of the extens=
ion point.=20

Based on this considerations, I propose the following text for Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. Public clients MUST use the=20
"code_challenge=E2=80=9D with a transaction-specific value that is sec=
urely=20
bound to the client and the user agent in which the transaction was=20
started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=9D=
 in the=20
same way or other suitable mechanisms to mitigate authorization code=20
injection.

This text follows the logic in Section 4.1.2.1 and allows use of the nonce =
for confidential clients.

best regards,
Torsten.=20



            

              
=

On 12. May 2020, at 02:21, Mike Jones &l=
t;Michael..Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

That works for me.  Thanks all for the useful back-and-forth that got us to=
 this point of clarity.  I suspect many of us learned things along the way;=
 I know that I did!

                                                    Cheers,
                                                    -- Mike

From: Aaron Parecki =
<aaron@parecki.com>
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG <oauth@=
ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>; Mike Jones=20
<Michae=
l.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to als=
o update section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. The use of the=20
`code_challenge` parameter is RECOMMENDED to this end. For=20
confidential clients, the OpenID Connect `nonce` parameter and ID=20
Token Claim {{OpenID}} MAY be used instead of or in addition to the=20
`code_challenge` parameter for this purpose. The `code_challenge`=20
or OpenID Connect `nonce` value MUST be transaction-specific and=20
securely bound to the client and the user agent in which the transaction wa=
s started.

This change better clarifies the specific circumstances under which the &qu=
ot;nonce" parameter is sufficient to protect against authorization cod=
e injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.madden@forgerock.com> wrot=
e:
I am happy with this proposed wording. Thanks for updating it.

=E2=80=94 Neil


On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com>
<=
blockquote type=3D"cite">
 wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20

We would like to propose the following text, which is a slight variation fr=
om the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-=
1-02#section-4.1..2.1) that begins with "If the client does not se=
nd the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clien=
ts, and MUST reject such requests from other clients unless there is reason=
able assurance that the client mitigates authorization code injection in ot=
her ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0=
 and 2.1 clients simultaneously. The change from Neil's text is the cla=
rification of which threats, and changing to MUST instead of SHOULD. The &q=
uot;MUST...unless" is more specific than "SHOULD", and since=
 we are already describing the explicit exception to the rule, it's mor=
e clear as a MUST here.

Aaron Parecki




_______________________________________________
OAuth mailing list

<=
blockquote type=3D"cite">
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

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


            

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


          

          

        

        

      

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


    


    

  


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

OAuth@ietf.org

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




--00000000000017de6505a5fa54f7--


From nobody Mon May 18 23:43:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3963A1259 for ; Mon, 18 May 2020 23:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level: 
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7frvOIhwoVT for ; Mon, 18 May 2020 23:43:51 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C933A1256 for ; Mon, 18 May 2020 23:43:50 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id E35184CAC; Tue, 19 May 2020 06:43:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1589870628; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pKZ4Ajvr66pX6OY6PiSZietjvpd4rRnSVvmSg+Jcub8=; b=d1Gs87Fw++fu0oIxYmdpvwjQj+HcGnk457W4r2lrp9u98H2hMwR1BMokI5sNgnCayZ308H ICWb56eFltG4tsmovWgne3c/YwTvqZF+HKA64vAMLW/H28hpDCfCdvJJMiz6KvXTbkKfxo y2A8vNL/Z/mH1v09RhoOEK4aO12wgdw=
To: Nov Matake 
Cc: "oauth@ietf.org" 
References:  <1bc5387b-d9a1-fa36-83d8-15756e9a1a51@danielfett.de> 
From: Daniel Fett 
Message-ID: <14646700-07c4-6a1b-0414-a6a9a52db903@danielfett.de>
Date: Tue, 19 May 2020 08:43:47 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A8664C72BFFF9CFA30D1C365"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1589870628; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pKZ4Ajvr66pX6OY6PiSZietjvpd4rRnSVvmSg+Jcub8=; b=soXO84PSGrZrRgqdmGVpy4VkNA6oLodXYNDnAi4v7P0cueKYfZhL7V5ZK0GViW7G3ZqI6k 10Cx8BnBq4B9wMPb/jX3rAn9Ee89uGx4aaHAFF85Y7vf9LmzKDOTvHbGE8SC1kfzYRipQ6 8ykiIgFQq2QjUxjIXRN7uSELkQWDBaA=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1589870628; a=rsa-sha256; cv=none; b=mddiUw7Kj/LwP2lkT3NiSyUWSKypg5WMDAW5Eu7oSZEhlRyw4ZK6XntQobdiChpw9BOgLd InAty50S0MTqBrTqMl1xx+O3XunxpBYiDP0K5aSSSSpWMIKJMCeE5vZ4gwAu4uRJYW1PMr fDIWJ5nyvazDBE67y6APFhne1OCdQyk=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 06:43:55 -0000

This is a multi-part message in MIME format.
--------------A8664C72BFFF9CFA30D1C365
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Hi,

Am 19.05.20 um 04:55 schrieb Nov Matake:
> I thought the server MUST reject such token requests, but I couldn’t
> find such definition in RFC7636...
>
> > The client will send the code, along with a (now not matching)
> code_verifier to the server. The server will ignore the code_verifier
> (as it was not expected) and send back an access token and ID token to
> the client.
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack
>
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack”
> would be possible.

I *think* that there is nothing preventing servers from sometimes using
PKCE and sometimes using Nonce. I assume that this is out of the scope
of the existing specifications.

I would be interested to hear how actual implementations handle this in
practice.

>
> Plus, with such AS behavior, CSRF protection using PKCE can also be
> bypassed as below.
> 1. The attacker removes code_challenge from his/her own AuthZ
> Req, receives a non-code_challenge-bound code, and sends it to the victim.
> 2. The client receives the attacker’s code from the victim, and sends
> it to the AS w/ the valid code_verifier bound to the victim’s browser
> session.
> 3. The AS ignores the code_verifier and returns tokens.
>
> If that’s the case, current OAuth 2.0 PKCE implementation can be
> weaker than expected..

Excellent point!

Would it be okay if I add that attack to the original post (with
credits, of course)?

-Daniel

>
> nov
>
>> 2020/05/19 1:54、Daniel Fett > >のメール:
>>
>> Hi all,
>>
>> Talking to Torsten, we realized that providing a generic extension
>> point here is probably not a good idea. It is really hard to tell
>> what protects you from code injection and what does not, and people
>> might come up with all sorts of non-standard and potentially insecure
>> solutions.
>>
>> Even just for PKCE vs. Nonce, it is not obvious if they provide the
>> same level of protection. In an attempt to answer this question, I
>> tried to come up with a more systematic analysis of "PKCE vs Nonce".
>> I wrote up my results here:
>> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>>
>> Although this is not a formal analysis, I hope that I have covered
>> all interesting cases. Please review the text and let me know if I
>> have missed something or if there are any mistakes.
>>
>> The main results are:
>>
>>  1. In terms of protection against CSRF and code misuse, PKCE and
>>     Nonce provide similar levels of security, with a slight advantage
>>     for PKCE.
>>  2. In practice, a circumvention of both mechanisms, however, is
>>     possible if an AS allows a client to choose between PKCE and
>>     Nonce and the client makes use of this freedom. I propose to call
>>     this attack the Nonce/PKCE Sidestep Attack. → Please review the
>>     attack description in the analysis.
>>  3. To avoid the Nonce/PKCE Sidestep Attack, clients must not switch
>>     between using only PKCE and only Nonce (but may use both in
>>     parallel, or switch between using only PKCE and PKCE+Nonce).
>>     Authorization servers must enforce PKCE unless they know that the
>>     client uses Nonce for all of its flows (and checks the Nonce
>>     value). The presence of a nonce parameter in the authorization
>>     request is not sufficient to determine if a client actually
>>     checks the nonce claim in the ID token.
>>
>> As you can see, already having two more-or-less well-understood
>> mechanisms is hard enough to wrap your head around from a security
>> standpoint. We should therefore make PKCE the default and Nonce an
>> option for backwards compatibility.
>>
>> To this end, I would like to propose the follwing strawman, based on
>> Torsten's and Aaron's suggestions:
>>
>> An AS MUST reject requests without a code_challenge from public
>> clients, and MUST reject such requests from other clients unless there
>> is reasonable assurance that the client mitigates authorization code
>> injection using the OpenID Connect Nonce mechanism and that this
>> mitigation is used for all interactions with the client. See section
>> 9.7 for details.
>>
>> Section 9.7:
>>
>> Clients MUST prevent injection (replay) of authorization codes into
>> the authorization response by attackers. The use of the
>> `code_challenge` parameter is RECOMMENDED to this end. For
>> confidential clients, the OpenID Connect `nonce` parameter and ID
>> Token Claim {{OpenID}} MAY be used instead of or in addition to the
>> `code_challenge` parameter for this purpose. The `code_challenge` or
>> OpenID Connect `nonce` value MUST be transaction-specific and securely
>> bound to the client and the user agent in which the transaction was
>> started.
>>
>> If the OpenID Connect `nonce` is used to mitigate authorization code
>> injection instead of `code_challenge`, client and authorization server
>> MUST ensure that the mitigation is applied to every interaction with
>> the client and that the client cannot switch between `code_challenge`
>> and `nonce`. For example, the presence of a `nonce` parameter in the
>> authorization request is not sufficient to determine that the
>> `code_verifier` check can be skipped.
>>
>>
>> Of course, we need to adapt the wording in the Security BCP accordingly.
>>
>> -Daniel
>>
>>
>>
>> Am 15.05.20 um 01:01 schrieb Mike Jones:
>>> I agree with Nov that obscuring the language in 9.7 would be a disservice to developers.
>>>
>>> The Security BCP, which has already going the WGLC, explicitly calls out the use of nonce as part of the best practices.  OAuth 2.1 should do no less.
>>>
>>> The 9.7 language that Aaron proposed was the result of many people's contributions and a vigorous discussion.  Let's publish the next version of 2.1 with that language intact, as I believe it represents at least a local point of hard-won consensus.  Let's get that language into the record of drafts.
>>>
>>> There's always time to debate it and change it later in subsequent drafts, but let's not now lose what it took a lot of effort to achieve.
>>>
>>> 				Thanks,
>>> 				-- Mike
>>>
>>> -----Original Message-----
>>> From: Nov Matake  
>>> Sent: Thursday, May 14, 2020 3:18 AM
>>> To: Torsten Lodderstedt 
>>> Cc: OAuth WG ; Mike Jones 
>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>
>>> There is no specific mechanism right now.
>>> But future developers won’t be able to read the reason why the extension point is given only for confidential clients.
>>>
>>>> On May 14, 2020, at 18:32, Torsten Lodderstedt  wrote:
>>>>
>>>> Are you aware of any suitable mechanism? I’m asking since from my perspective this clause is mainly intended to allow existing OpenID Connect deployments to use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I think we should not encourage others to invent their own OAuth security mechanisms. 
>>>>
>>>>> On 14. May 2020, at 09:37, Nov Matake  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Why not allowing public clients use "other suitable mechanisms” then?
>>>>> OAuth WG can allow both type of clients do so, then OIDF will define nonce as the alternative only for confidential clients.
>>>>>
>>>>>> 2020/05/14 15:56、Torsten Lodderstedt のメール:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I would also like to thank everybody for the substantial discussion.  
>>>>>>
>>>>>> The proposed change for Section 4.1.2.1 works for me (as already stated). I’m not fully comfortable with the proposed change for Section 9.7 for the following reasons:
>>>>>>
>>>>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE instead of requiring it (with a well-defined exception).
>>>>>> - Given the latest findings re nonce I don’t feel comfortable with recommending any mechanism that this WG is not responsible for and thus did not conduct the security threat analysis for. I think the better way for us as WG is to define the extension point for other mechanisms. The OpenID Foundation (or any other body) can then fill in and issue a statement that nonce (or another suitable mechanism) fulfils the requirements of the extension point. 
>>>>>>
>>>>>> Based on this considerations, I propose the following text for Section 9.7:
>>>>>>
>>>>>> Clients MUST prevent injection (replay) of authorization codes into 
>>>>>> the authorization response by attackers. Public clients MUST use the 
>>>>>> "code_challenge” with a transaction-specific value that is securely 
>>>>>> bound to the client and the user agent in which the transaction was 
>>>>>> started. Confidential clients MUST use the “code_challenge” in the 
>>>>>> same way or other suitable mechanisms to mitigate authorization code 
>>>>>> injection.
>>>>>>
>>>>>> This text follows the logic in Section 4.1.2.1 and allows use of the nonce for confidential clients.
>>>>>>
>>>>>> best regards,
>>>>>> Torsten. 
>>>>>>
>>>>>>> On 12. May 2020, at 02:21, Mike Jones  wrote:
>>>>>>>
>>>>>>> That works for me.  Thanks all for the useful back-and-forth that got us to this point of clarity.  I suspect many of us learned things along the way; I know that I did!
>>>>>>>
>>>>>>>                                                     Cheers,
>>>>>>>                                                     -- Mike
>>>>>>>
>>>>>>> From: Aaron Parecki 
>>>>>>> Sent: Monday, May 11, 2020 4:55 PM
>>>>>>> To: OAuth WG 
>>>>>>> Cc: Neil Madden ; Mike Jones 
>>>>>>> 
>>>>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>>>>>
>>>>>>> Thank you Neil.
>>>>>>>
>>>>>>> To address Mike's concerns in the previous threads, I would like to also update section 9.7 with the following text:
>>>>>>>
>>>>>>> Clients MUST prevent injection (replay) of authorization codes into 
>>>>>>> the authorization response by attackers. The use of the 
>>>>>>> `code_challenge` parameter is RECOMMENDED to this end. For 
>>>>>>> confidential clients, the OpenID Connect `nonce` parameter and ID 
>>>>>>> Token Claim {{OpenID}} MAY be used instead of or in addition to the 
>>>>>>> `code_challenge` parameter for this purpose. The `code_challenge` 
>>>>>>> or OpenID Connect `nonce` value MUST be transaction-specific and 
>>>>>>> securely bound to the client and the user agent in which the transaction was started.
>>>>>>>
>>>>>>> This change better clarifies the specific circumstances under which the "nonce" parameter is sufficient to protect against authorization code injection.
>>>>>>>
>>>>>>> Aaron Parecki
>>>>>>>
>>>>>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden  wrote:
>>>>>>> I am happy with this proposed wording. Thanks for updating it.
>>>>>>>
>>>>>>> — Neil
>>>>>>>
>>>>>>>
>>>>>>> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>>>>>>>
>>>>>>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! 
>>>>>>>
>>>>>>> We would like to propose the following text, which is a slight variation from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins with "If the client does not send the "code_challenge" in the request..."
>>>>>>>
>>>>>>> "An AS MUST reject requests without a code_challenge from public clients, and MUST reject such requests from other clients unless there is reasonable assurance that the client mitigates authorization code injection in other ways. See section 9.7 for details."
>>>>>>>
>>>>>>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>>>>>>
>>>>>>> As Neil described, we believe this will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is the clarification of which threats, and changing to MUST instead of SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we are already describing the explicit exception to the rule, it's more clear as a MUST here.
>>>>>>>
>>>>>>> Aaron Parecki
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>


--------------A8664C72BFFF9CFA30D1C365
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi,

    

    


    

    
Am 19.05.20 um 04:55 schrieb Nov
      Matake:

    

    

      
      I thought the server MUST reject such token requests, but I
      couldn’t find such definition in RFC7636...
      

        


        

        

          
> The client will send the code, along with a
            (now not matching) code_verifier to the server. The server
            will ignore the code_verifier (as it was not expected) and
            send back an access token and ID token to the client.

          
          


          

          

            
If the behavior is acceptable by RFC7636,
              "Nonce/PKCE Sidestep Attack” would be possible.

          

        

      

    

    
I *think* that there is nothing preventing servers from sometimes
      using PKCE and sometimes using Nonce. I assume that this is out of
      the scope of the existing specifications. 

    

    
I would be interested to hear how actual implementations handle
      this in practice.

    

    

      

        

          


          

          
Plus, with such AS behavior, CSRF protection
            using PKCE can also be bypassed as below.

          
1. The attacker removes code_challenge from
            his/her own AuthZ Req, receives a non-code_challenge-bound
            code, and sends it to the victim.

          
2. The client receives the attacker’s code from
            the victim, and sends it to the AS w/ the valid
            code_verifier bound to the victim’s browser session.

          
3. The AS ignores the code_verifier and returns
            tokens.

          


          

          
If that’s the case, current OAuth 2.0 PKCE
            implementation can be weaker than expected..

        

      

    

    
Excellent point!

    

    
Would it be okay if I add that attack to the original post (with
      credits, of course)?

    
-Daniel

    

    

      

        

          


          

          
nov

          

            


              

                
2020/05/19 1:54、Daniel Fett <fett@danielfett.de>のメール:

                

                

                  
                  

                    
Hi all,

                    


                    

                    
Talking to Torsten, we
                      realized that providing a generic extension point
                      here is probably not a good idea. It is really
                      hard to tell what protects you from code injection
                      and what does not, and people might come up with
                      all sorts of non-standard and potentially insecure
                      solutions. 

                    

                    


                    

                    
Even just for PKCE vs.
                      Nonce, it is not obvious if they provide the same
                      level of protection. In an attempt to answer this
                      question, I tried to come up with a more
                      systematic analysis of "PKCE vs Nonce". I wrote up
                      my results here: 

                    

                    
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

                    

                    

                    Although this is not a formal analysis, I hope that
                    I have covered all interesting cases. Please review
                    the text and let me know if I have missed something
                    or if there are any mistakes.

                    

                    The main results are:

                    
    
                      
  1. In terms of protection against CSRF
                        and code misuse, PKCE and Nonce provide similar
                        levels of security, with a slight advantage for
                        PKCE.
    2. 
                      
  2. In practice, a circumvention of both
                        mechanisms, however, is possible if an AS allows
                        a client to choose between PKCE and Nonce and
                        the client makes use of this freedom. I propose
                        to call this attack the Nonce/PKCE Sidestep
                        Attack. → Please review the attack description
                        in the analysis.
    3. 
                      
  3. To avoid the Nonce/PKCE Sidestep
                        Attack, clients must not switch between using
                        only PKCE and only Nonce (but may use both in
                        parallel, or switch between using only PKCE and
                        PKCE+Nonce). Authorization servers must enforce
                        PKCE unless they know that the client uses Nonce
                        for all of its flows (and checks the Nonce
                        value). The presence of a nonce parameter in the
                        authorization request is not sufficient to
                        determine if a client actually checks the nonce
                        claim in the ID token.
    4. 
                    

                    
As you can see, already having two
                      more-or-less well-understood mechanisms is hard
                      enough to wrap your head around from a security
                      standpoint. We should therefore make PKCE the
                      default and Nonce an option for backwards
                      compatibility.

                    

                    
To this end, I would like to propose the
                      follwing strawman, based on Torsten's and Aaron's
                      suggestions:

                    An AS MUST reject requests without a
                      code_challenge from public

                    clients, and MUST reject such
                      requests from other clients unless there

                    is reasonable assurance that the
                      client mitigates authorization code

                    injection using the OpenID Connect
                      Nonce mechanism and that this

                    mitigation is used for all
                      interactions with the client. See section

                    9.7 for details.

                    

                    Section 9.7:

                    

                    Clients MUST prevent injection (replay)
                      of authorization codes into

                    the authorization response by
                      attackers. The use of the

                    `code_challenge` parameter is
                      RECOMMENDED to this end. For

                    confidential clients, the OpenID
                      Connect `nonce` parameter and ID

                    Token Claim {{OpenID}} MAY be used
                      instead of or in addition to the

                    `code_challenge` parameter for
                      this purpose. The `code_challenge` or

                    OpenID Connect `nonce` value MUST
                      be transaction-specific and securely

                    bound to the client and the user
                      agent in which the transaction was

                    started.

                    

                    If the OpenID Connect `nonce` is
                      used to mitigate authorization code

                    injection instead of
                      `code_challenge`, client and authorization server

                    MUST ensure that the mitigation is
                      applied to every interaction with

                    the client and that the client
                      cannot switch between `code_challenge`

                    and `nonce`. For example, the
                      presence of a `nonce` parameter in the

                    authorization request is not
                      sufficient to determine that the

                    `code_verifier` check can be
                      skipped.

                    


                    

                    
Of course, we need to adapt the wording
                      in the Security BCP accordingly.

                    
-Daniel

                    

                    


                    

                    


                    

                    
Am 15.05.20 um 01:01
                      schrieb Mike Jones:

                    

                    

                      
I agree with Nov that obscuring the language in 9.7 would be a disservice to developers.

The Security BCP, which has already going the WGLC, explicitly calls out the use of nonce as part of the best practices.  OAuth 2.1 should do no less.

The 9.7 language that Aaron proposed was the result of many people's contributions and a vigorous discussion.  Let's publish the next version of 2.1 with that language intact, as I believe it represents at least a local point of hard-won consensus.  Let's get that language into the record of drafts.

There's always time to debate it and change it later in subsequent drafts, but let's not now lose what it took a lot of effort to achieve.

				Thanks,
				-- Mike

-----Original Message-----
From: Nov Matake <matake@gmail.com> 
Sent: Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

There is no specific mechanism right now.
But future developers won’t be able to read the reason why the extension point is given only for confidential clients.



                      

                        
On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Are you aware of any suitable mechanism? I’m asking since from my perspective this clause is mainly intended to allow existing OpenID Connect deployments to use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I think we should not encourage others to invent their own OAuth security mechanisms. 



                        

                          
On 14. May 2020, at 09:37, Nov Matake <matake@gmail.com> wrote:

Hi,

Why not allowing public clients use "other suitable mechanisms” then?
OAuth WG can allow both type of clients do so, then OIDF will define nonce as the alternative only for confidential clients.



                          

                            
2020/05/14 15:56、Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>のメール:

Hi all,

I would also like to thank everybody for the substantial discussion.  

The proposed change for Section 4.1.2.1 works for me (as already stated). I’m not fully comfortable with the proposed change for Section 9.7 for the following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE instead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don’t feel comfortable with recommending any mechanism that this WG is not responsible for and thus did not conduct the security threat analysis for. I think the better way for us as WG is to define the extension point for other mechanisms. The OpenID Foundation (or any other body) can then fill in and issue a statement that nonce (or another suitable mechanism) fulfils the requirements of the extension point. 

Based on this considerations, I propose the following text for Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into 
the authorization response by attackers. Public clients MUST use the 
"code_challenge” with a transaction-specific value that is securely 
bound to the client and the user agent in which the transaction was 
started. Confidential clients MUST use the “code_challenge” in the 
same way or other suitable mechanisms to mitigate authorization code 
injection.

This text follows the logic in Section 4.1.2.1 and allows use of the nonce for confidential clients.

best regards,
Torsten. 



                            

                              
On 12. May 2020, at 02:21, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

That works for me.  Thanks all for the useful back-and-forth that got us to this point of clarity.  I suspect many of us learned things along the way; I know that I did!

                                                    Cheers,
                                                    -- Mike

From: Aaron Parecki <aaron@parecki.com>
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>; Mike Jones 
<Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also update section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into 
the authorization response by attackers. The use of the 
`code_challenge` parameter is RECOMMENDED to this end. For 
confidential clients, the OpenID Connect `nonce` parameter and ID 
Token Claim {{OpenID}} MAY be used instead of or in addition to the 
`code_challenge` parameter for this purpose. The `code_challenge` 
or OpenID Connect `nonce` value MUST be transaction-specific and 
securely bound to the client and the user agent in which the transaction was started.

This change better clarifies the specific circumstances under which the "nonce" parameter is sufficient to protect against authorization code injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.madden@forgerock.com> wrote:
I am happy with this proposed wording. Thanks for updating it.

— Neil


On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! 

We would like to propose the following text, which is a slight variation from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins with "If the client does not send the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clients, and MUST reject such requests from other clients unless there is reasonable assurance that the client mitigates authorization code injection in other ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is the clarification of which threats, and changing to MUST instead of SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we are already describing the explicit exception to the rule, it's more clear as a MUST here.

Aaron Parecki




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

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


                            

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


                          

                        

                      

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


                    

                    


                    

                  

                  _______________________________________________

                  OAuth mailing list

                  OAuth@ietf.org

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

                

              

            

            

          

        

      

    

    


    

  


--------------A8664C72BFFF9CFA30D1C365--


From nobody Mon May 18 23:50:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2D73A1258 for ; Mon, 18 May 2020 23:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level: 
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5g9blqoDMaP for ; Mon, 18 May 2020 23:50:19 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E9E3A125B for ; Mon, 18 May 2020 23:50:19 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id u35so5944293pgk.6 for ; Mon, 18 May 2020 23:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=cawxnkT5+UdXaPEybh2K3nzq1o1gvSP1oCPVZgDB+0s=; b=OrLCISVeLIqsLGchkbpCcDTJW1ljRyRkUiRvr8mI/0ZO6EHcQP3kRtLj6grmd+BAoM trCe1NECyavPDoN22rSkt2ooxwtSM+auVIWuIJ4fH2BBg0Y4OlyD/fOvPGYH/6Jb/NRT nArp1gmhDs937Fs6QMbNTZ0+CImupbPfM4KuYlGt0nnzyZILSFRcAD4cJFFjUjdQUsuz ctJKiw8+JgesYblqr1id09TYU1HvEmtYaCTtyzR+dSsCCSOe77mpMGFlgGfd8+fUMUag sJ17okqfOJI1eNRROeZTFrmO4Ikqop13RRw328MGIcZtTIjWNBxHrpz1kadQ4LVuz25k pmTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=cawxnkT5+UdXaPEybh2K3nzq1o1gvSP1oCPVZgDB+0s=; b=S8EARgxAaQPDGpH0dnj+sl8aVKsBlEtLyggJTm9RWptV/pw/dK+l7hXp4jVGr1eVAR DlUE1IHO996Np5QEruOzH5kc/vDl7VXJqBNAJC5An4DpwH8CIc37d4mCfeCBWa5dAf5Z sif/q8r92sXEHAHjmhqrTN5JqVKfyKq9ln26hjYFEKkSP0k0KgWeYNVF9g6Eg89uiDSf gPAAyxaebE8Y2L67qasmo3hwlxZN9h4ToyPmKdOvC3CgSUmkjzUuiuAyhw1U5AvimrMm jLpxKdzPmtCvdrzhgu3M4IL+spPD2m10U6iAWKb8PcONqFHiky7Rb0EY6UNQ9C7pVNNt hqTg==
X-Gm-Message-State: AOAM531UWyInEXZJTJGT/hxPZRnInqYpUtx5IvTvBHcK8Ha0Xex8/GpZ +gXU2LirGAY8Eo0dt99yyX/IcHh5rlI=
X-Google-Smtp-Source: ABdhPJz9pvmq1M0uhMsUkAn1aHTkzu6c+8z0RPXgl1iwuPD5YayN3H//Zu3D1JFGahLRZzCQnY9ayw==
X-Received: by 2002:a63:d954:: with SMTP id e20mr18198287pgj.360.1589871018396;  Mon, 18 May 2020 23:50:18 -0700 (PDT)
Received: from [172.16.80.56] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id e26sm3324135pgl.27.2020.05.18.23.50.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 23:50:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-9FB001C3-9474-4336-A965-9A1976FD4F56
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Nov Matake 
In-Reply-To: <14646700-07c4-6a1b-0414-a6a9a52db903@danielfett.de>
Cc: "oauth@ietf.org" 
Date: Tue, 19 May 2020 15:50:16 +0900
Message-Id: <9B54DA4A-ED50-432B-8B32-D0602BB9D2FA@gmail.com>
References: <14646700-07c4-6a1b-0414-a6a9a52db903@danielfett.de>
To: Daniel Fett 
X-Mailer: iPad Mail (17E262)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 06:50:23 -0000

--Apple-Mail-9FB001C3-9474-4336-A965-9A1976FD4F56
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sure, feel free to add the senario to your post.

FYI:
my OAuth2 server ruby gem rejects such token requests,
https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extens=
ion/pkce.rb#L28
and Google also does the same.
https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046

So I'm guessing such behavior is relatively rare-case, hopefully.

iPad=E3=81=8B=E3=82=89=E9=80=81=E4=BF=A1

> 2020/05/19 15:43=E3=80=81Daniel Fett =E3=81=AE=E3=83=A1=
=E3=83=BC=E3=83=AB:
> =EF=BB=BF
> Hi,
>=20
> Am 19.05.20 um 04:55 schrieb Nov Matake:
>> I thought the server MUST reject such token requests, but I couldn=E2=80=99=
t find such definition in RFC7636...
>>=20
>> > The client will send the code, along with a (now not matching) code_ver=
ifier to the server. The server will ignore the code_verifier (as it was not=
 expected) and send back an access token and ID token to the client.
>> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepk=
ce-sidestep-attack
>>=20
>> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2=80=
=9D would be possible.
> I *think* that there is nothing preventing servers from sometimes using PK=
CE and sometimes using Nonce. I assume that this is out of the scope of the e=
xisting specifications.=20
>=20
> I would be interested to hear how actual implementations handle this in pr=
actice.
>=20
>>=20
>> Plus, with such AS behavior, CSRF protection using PKCE can also be bypas=
sed as below.
>> 1. The attacker removes code_challenge from his/her own AuthZ Req, receiv=
es a non-code_challenge-bound code, and sends it to the victim.
>> 2. The client receives the attacker=E2=80=99s code from the victim, and s=
ends it to the AS w/ the valid code_verifier bound to the victim=E2=80=99s b=
rowser session.
>> 3. The AS ignores the code_verifier and returns tokens.
>>=20
>> If that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can be w=
eaker than expected..
> Excellent point!
>=20
> Would it be okay if I add that attack to the original post (with credits, o=
f course)?
>=20
> -Daniel
>=20
>>=20
>> nov
>>=20
>>> 2020/05/19 1:54=E3=80=81Daniel Fett =E3=81=AE=E3=83=A1=
=E3=83=BC=E3=83=AB:
>>>=20
>>> Hi all,
>>>=20
>>> Talking to Torsten, we realized that providing a generic extension point=
 here is probably not a good idea. It is really hard to tell what protects y=
ou from code injection and what does not, and people might come up with all s=
orts of non-standard and potentially insecure solutions.=20
>>>=20
>>> Even just for PKCE vs. Nonce, it is not obvious if they provide the same=
 level of protection. In an attempt to answer this question, I tried to come=
 up with a more systematic analysis of "PKCE vs Nonce". I wrote up my result=
s here:=20
>>> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>>>=20
>>> Although this is not a formal analysis, I hope that I have covered all i=
nteresting cases. Please review the text and let me know if I have missed so=
mething or if there are any mistakes.
>>>=20
>>> The main results are:
>>> In terms of protection against CSRF and code misuse, PKCE and Nonce prov=
ide similar levels of security, with a slight advantage for PKCE.
>>> In practice, a circumvention of both mechanisms, however, is possible if=
 an AS allows a client to choose between PKCE and Nonce and the client makes=
 use of this freedom. I propose to call this attack the Nonce/PKCE Sidestep A=
ttack. =E2=86=92 Please review the attack description in the analysis.
>>> To avoid the Nonce/PKCE Sidestep Attack, clients must not switch between=
 using only PKCE and only Nonce (but may use both in parallel, or switch bet=
ween using only PKCE and PKCE+Nonce). Authorization servers must enforce PKC=
E unless they know that the client uses Nonce for all of its flows (and chec=
ks the Nonce value). The presence of a nonce parameter in the authorization r=
equest is not sufficient to determine if a client actually checks the nonce c=
laim in the ID token.
>>> As you can see, already having two more-or-less well-understood mechanis=
ms is hard enough to wrap your head around from a security standpoint. We sh=
ould therefore make PKCE the default and Nonce an option for backwards compa=
tibility.
>>>=20
>>> To this end, I would like to propose the follwing strawman, based on Tor=
sten's and Aaron's suggestions:
>>>=20
>>> An AS MUST reject requests without a code_challenge from public
>>> clients, and MUST reject such requests from other clients unless there
>>> is reasonable assurance that the client mitigates authorization code
>>> injection using the OpenID Connect Nonce mechanism and that this
>>> mitigation is used for all interactions with the client. See section
>>> 9.7 for details.
>>>=20
>>> Section 9.7:
>>>=20
>>> Clients MUST prevent injection (replay) of authorization codes into
>>> the authorization response by attackers. The use of the
>>> `code_challenge` parameter is RECOMMENDED to this end. For
>>> confidential clients, the OpenID Connect `nonce` parameter and ID
>>> Token Claim {{OpenID}} MAY be used instead of or in addition to the
>>> `code_challenge` parameter for this purpose. The `code_challenge` or
>>> OpenID Connect `nonce` value MUST be transaction-specific and securely
>>> bound to the client and the user agent in which the transaction was
>>> started.
>>>=20
>>> If the OpenID Connect `nonce` is used to mitigate authorization code
>>> injection instead of `code_challenge`, client and authorization server
>>> MUST ensure that the mitigation is applied to every interaction with
>>> the client and that the client cannot switch between `code_challenge`
>>> and `nonce`. For example, the presence of a `nonce` parameter in the
>>> authorization request is not sufficient to determine that the
>>> `code_verifier` check can be skipped.
>>>=20
>>>=20
>>> Of course, we need to adapt the wording in the Security BCP accordingly.=

>>>=20
>>> -Daniel
>>>=20
>>>=20
>>>=20
>>>=20
>>> Am 15.05.20 um 01:01 schrieb Mike Jones:
>>>> I agree with Nov that obscuring the language in 9.7 would be a disservi=
ce to developers.
>>>>=20
>>>> The Security BCP, which has already going the WGLC, explicitly calls ou=
t the use of nonce as part of the best practices.  OAuth 2.1 should do no le=
ss.
>>>>=20
>>>> The 9.7 language that Aaron proposed was the result of many people's co=
ntributions and a vigorous discussion.  Let's publish the next version of 2.=
1 with that language intact, as I believe it represents at least a local poi=
nt of hard-won consensus.  Let's get that language into the record of drafts=
.
>>>>=20
>>>> There's always time to debate it and change it later in subsequent draf=
ts, but let's not now lose what it took a lot of effort to achieve.
>>>>=20
>>>> 				Thanks,
>>>> 				-- Mike
>>>>=20
>>>> -----Original Message-----
>>>> From: Nov Matake =20
>>>> Sent: Thursday, May 14, 2020 3:18 AM
>>>> To: Torsten Lodderstedt 
>>>> Cc: OAuth WG ; Mike Jones =

>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>>=20
>>>> There is no specific mechanism right now.
>>>> But future developers won=E2=80=99t be able to read the reason why the e=
xtension point is given only for confidential clients.
>>>>=20
>>>>>>> On May 14, 2020, at 18:32, Torsten Lodderstedt  wrote:
>>>>>>>=20
>>>>>>> Are you aware of any suitable mechanism? I=E2=80=99m asking since fr=
om my perspective this clause is mainly intended to allow existing OpenID Co=
nnect deployments to use nonce instead of PKCE in combination with OAuth 2.1=
. It=E2=80=99s a compromise. I think we should not encourage others to inven=
t their own OAuth security mechanisms.=20
>>>>>>>=20
>>>>>>>> On 14. May 2020, at 09:37, Nov Matake  wrote:
>>>>>>>>=20
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> Why not allowing public clients use "other suitable mechanisms=E2=80=
=9D then?
>>>>>>>> OAuth WG can allow both type of clients do so, then OIDF will defin=
e nonce as the alternative only for confidential clients.
>>>>>>>>=20
>>>>>>>> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
>>>>>>>>=20
>>>>>>>> Hi all,
>>>>>>>>=20
>>>>>>>> I would also like to thank everybody for the substantial discussion=
. =20
>>>>>>>>=20
>>>>>>>> The proposed change for Section 4.1.2.1 works for me (as already st=
ated). I=E2=80=99m not fully comfortable with the proposed change for Sectio=
n 9.7 for the following reasons:
>>>>>>>>=20
>>>>>>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use o=
f PKCE instead of requiring it (with a well-defined exception).
>>>>>>>> - Given the latest findings re nonce I don=E2=80=99t feel comfortab=
le with recommending any mechanism that this WG is not responsible for and t=
hus did not conduct the security threat analysis for. I think the better way=
 for us as WG is to define the extension point for other mechanisms. The Ope=
nID Foundation (or any other body) can then fill in and issue a statement th=
at nonce (or another suitable mechanism) fulfils the requirements of the ext=
ension point.=20
>>>>>>>>=20
>>>>>>>> Based on this considerations, I propose the following text for Sect=
ion 9.7:
>>>>>>>>=20
>>>>>>>> Clients MUST prevent injection (replay) of authorization codes into=
=20
>>>>>>>> the authorization response by attackers. Public clients MUST use th=
e=20
>>>>>>>> "code_challenge=E2=80=9D with a transaction-specific value that is s=
ecurely=20
>>>>>>>> bound to the client and the user agent in which the transaction was=
=20
>>>>>>>> started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=
=80=9D in the=20
>>>>>>>> same way or other suitable mechanisms to mitigate authorization cod=
e=20
>>>>>>>> injection.
>>>>>>>>=20
>>>>>>>> This text follows the logic in Section 4.1.2.1 and allows use of th=
e nonce for confidential clients.
>>>>>>>>=20
>>>>>>>> best regards,
>>>>>>>> Torsten.=20
>>>>>>>>=20
>>>>>>>> On 12. May 2020, at 02:21, Mike Jones  wrote:
>>>>>>>>=20
>>>>>>>> That works for me.  Thanks all for the useful back-and-forth that g=
ot us to this point of clarity.  I suspect many of us learned things along t=
he way; I know that I did!
>>>>>>>>=20
>>>>>>>>                                                     Cheers,
>>>>>>>>                                                     -- Mike
>>>>>>>>=20
>>>>>>>> From: Aaron Parecki 
>>>>>>>> Sent: Monday, May 11, 2020 4:55 PM
>>>>>>>> To: OAuth WG 
>>>>>>>> Cc: Neil Madden ; Mike Jones=20
>>>>>>>> 
>>>>>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>>>>>>=20
>>>>>>>> Thank you Neil.
>>>>>>>>=20
>>>>>>>> To address Mike's concerns in the previous threads, I would like to=
 also update section 9.7 with the following text:
>>>>>>>>=20
>>>>>>>> Clients MUST prevent injection (replay) of authorization codes into=
=20
>>>>>>>> the authorization response by attackers. The use of the=20
>>>>>>>> `code_challenge` parameter is RECOMMENDED to this end. For=20
>>>>>>>> confidential clients, the OpenID Connect `nonce` parameter and ID=20=

>>>>>>>> Token Claim {{OpenID}} MAY be used instead of or in addition to the=
=20
>>>>>>>> `code_challenge` parameter for this purpose. The `code_challenge`=20=

>>>>>>>> or OpenID Connect `nonce` value MUST be transaction-specific and=20=

>>>>>>>> securely bound to the client and the user agent in which the transa=
ction was started.
>>>>>>>>=20
>>>>>>>> This change better clarifies the specific circumstances under which=
 the "nonce" parameter is sufficient to protect against authorization code i=
njection.
>>>>>>>>=20
>>>>>>>> Aaron Parecki
>>>>>>>>=20
>>>>>>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden  wrote:
>>>>>>>> I am happy with this proposed wording. Thanks for updating it.
>>>>>>>>=20
>>>>>>>> =E2=80=94 Neil
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>>>>>>>>=20
>>>>>>>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=
=20
>>>>>>>>=20
>>>>>>>> We would like to propose the following text, which is a slight vari=
ation from the text Neil proposed. This would replace the paragraph in 4.1.2=
.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1)=
 that begins with "If the client does not send the "code_challenge" in the r=
equest..."
>>>>>>>>=20
>>>>>>>> "An AS MUST reject requests without a code_challenge from public cl=
ients, and MUST reject such requests from other clients unless there is reas=
onable assurance that the client mitigates authorization code injection in o=
ther ways. See section 9.7 for details."
>>>>>>>>=20
>>>>>>>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>>>>>>>=20
>>>>>>>> As Neil described, we believe this will allow ASs to support both O=
Auth 2.0 and 2.1 clients simultaneously. The change from Neil's text is the c=
larification of which threats, and changing to MUST instead of SHOULD. The "=
MUST...unless" is more specific than "SHOULD", and since we are already desc=
ribing the explicit exception to the rule, it's more clear as a MUST here.
>>>>>>>>=20
>>>>>>>> Aaron Parecki
>>>>>>>>=20
>>>>>>>>=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
>>>> _______________________________________________
>>>> 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-9FB001C3-9474-4336-A965-9A1976FD4F56
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Sure, feel free to add the=
 senario to your post.

FYI:=

my OAuth2 server ruby gem rejects such token requests,
and Google also does the same.=

https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046

So I'm guessing such behavior is relatively rare-case,=
 hopefully.

iPad=E3=81=8B=E3=82=89=E9=80=81=E4=
=BF=A1

2020/05/19 15:43=E3=
=80=81Daniel Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=
=AB:

=EF=
=BB=BF
 =20
    
 =20
 =20
    
Hi,

    

    


    

    
Am 19.05.20 um 04:55 schrieb Nov
      Matake:

    

    

      
      I thought the server MUST reject such token requests, but I
      couldn=E2=80=99t find such definition in RFC7636...
      

        


        

        

          
> The client will send the code, along wit=
h a
            (now not matching) code_verifier to the server. The server
            will ignore the code_verifier (as it was not expected) and
            send back an access token and ID token to the client.

          
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-n=
ot/#noncepkce-sidestep-attack

          


          

          

            
If the behavior is acceptable by RFC7636,
              "Nonce/PKCE Sidestep Attack=E2=80=9D would be possible.

          

        

      

    

    
I *think* that there is nothing preventing servers from sometimes
      using PKCE and sometimes using Nonce. I assume that this is out of
      the scope of the existing specifications. 

    

    
I would be interested to hear how actual implementations handle
      this in practice.

    

    

      

        

          


          

          
Plus, with such AS behavior, CSRF protection
            using PKCE can also be bypassed as below.

          
1. The attacker removes code_challenge from
            his/her own AuthZ Req, receives a non-code_challenge-b=
ound
            code, and sends it to the victim.

          
2. The client receives the attacker=E2=80=99s code=
 from
            the victim, and sends it to the AS w/ the valid
            code_verifier bound to the victim=E2=80=99s browser session.
          
3. The AS ignores the code_verifier and returns
            tokens.

          


          

          
If that=E2=80=99s the case, current OAuth 2.0 PKCE=

            implementation can be weaker than expected..

        

      

    

    
Excellent point!

    

    
Would it be okay if I add that attack to the original post (with
      credits, of course)?

    
-Daniel

    

    

      

        

          


          

          
nov

          

            


              

                
2020/05/19 1:54=E3=80=81Daniel Fett <fett@d=
anielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

                

                

                  
                  

                    
Hi all,

                    


                    

                    
Talking to Torsten, we
                      realized that providing a generic extension point
                      here is probably not a good idea. It is really
                      hard to tell what protects you from code injection
                      and what does not, and people might come up with
                      all sorts of non-standard and potentially insecure
                      solutions. 

                    

                    


                    

                    
Even just for PKCE vs.
                      Nonce, it is not obvious if they provide the same
                      level of protection. In an attempt to answer this
                      question, I tried to come up with a more
                      systematic analysis of "PKCE vs Nonce". I wrote up
                      my results here: 

                    

                    
https://danielfett.de/2020/05/16/pkce-vs-n=
once-equivalent-or-not/

                    

                    

                    Although this is not a formal analysis, I hope that
                    I have covered all interesting cases. Please review
                    the text and let me know if I have missed something
                    or if there are any mistakes.

                    

                    The main results are:

                    
    
                      
  1. In terms of protection against CSRF
                        and code misuse, PKCE and Nonce provide similar
                        levels of security, with a slight advantage for
                        PKCE.
    2. 
                      
  2. In practice, a circumvention of both
                        mechanisms, however, is possible if an AS allows
                        a client to choose between PKCE and Nonce and
                        the client makes use of this freedom. I propose
                        to call this attack the Nonce/PKCE Sidestep
                        Attack. =E2=86=92 Please review the attack descripti=
on
                        in the analysis.
    3. 
                      
  3. To avoid the Nonce/PKCE Sidestep
                        Attack, clients must not switch between using
                        only PKCE and only Nonce (but may use both in
                        parallel, or switch between using only PKCE and
                        PKCE+Nonce). Authorization servers must enforce
                        PKCE unless they know that the client uses Nonce
                        for all of its flows (and checks the Nonce
                        value). The presence of a nonce parameter in the
                        authorization request is not sufficient to
                        determine if a client actually checks the nonce
                        claim in the ID token.
    4. 
                    

                    
As you can see, already having two
                      more-or-less well-understood mechanisms is hard
                      enough to wrap your head around from a security
                      standpoint. We should therefore make PKCE the
                      default and Nonce an option for backwards
                      compatibility.

                    

                    
To this end, I would like to propose the
                      follwing strawman, based on Torsten's and Aaron's
                      suggestions:

                    An AS MUST reject requests without a
                      code_challenge from public

                    clients, and MUST reject such
                      requests from other clients unless there

                    is reasonable assurance that the
                      client mitigates authorization code

                    injection using the OpenID Connect
                      Nonce mechanism and that this

                    mitigation is used for all
                      interactions with the client. See section

                    9.7 for details.
=

                    

                    Section 9.7:

                    

                    Clients MUST prevent injection (replay)
                      of authorization codes into

                    the authorization response by
                      attackers. The use of the

                    `code_challenge` parameter is
                      RECOMMENDED to this end. For

                    confidential clients, the OpenID
                      Connect `nonce` parameter and ID
                    Token Claim {{OpenID}} MAY be used
                      instead of or in addition to the
                    `code_challenge` parameter for
                      this purpose. The `code_challenge` or

                    OpenID Connect `nonce` value MUST
                      be transaction-specific and securely

                    bound to the client and the user
                      agent in which the transaction was=


                    started.

                    

                    If the OpenID Connect `nonce` is
                      used to mitigate authorization code

                    injection instead of
                      `code_challenge`, client and authorization server=


                    MUST ensure that the mitigation is
                      applied to every interaction with<=
br class=3D"">
                    the client and that the client
                      cannot switch between `code_challenge`

                    and `nonce`. For example, the
                      presence of a `nonce` parameter in the

                    authorization request is not
                      sufficient to determine that the
                    `code_verifier` check can be
                      skipped.

                    


                    

                    
Of course, we need to adapt the wording
                      in the Security BCP accordingly.

                    
-Daniel

                    

                    


                    

                    


                    

                    
Am 15.05.20 um 01:01
                      schrieb Mike Jones:

                    

                    

                      
I agree with No=
v that obscuring the language in 9.7 would be a disservice to developers.

The Security BCP, which has already going the WGLC, explicitly calls out the=
 use of nonce as part of the best practices.  OAuth 2.1 should do no less.

The 9.7 language that Aaron proposed was the result of many people's contrib=
utions and a vigorous discussion.  Let's publish the next version of 2.1 wit=
h that language intact, as I believe it represents at least a local point of=
 hard-won consensus.  Let's get that language into the record of drafts.

There's always time to debate it and change it later in subsequent drafts, b=
ut let's not now lose what it took a lot of effort to achieve.

				Thanks,
				-- Mike

-----Original Message-----
From: Nov Matake <matake@gmail.com>=20
Sent: Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net&=
gt;
Cc: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

There is no specific mechanism right now.
But future developers won=E2=80=99t be able to read the reason why the exten=
sion point is given only for confidential clients.



                      

                        
On May 14, 20=
20, at 18:32, Torsten Lodderstedt <torsten@lodder=
stedt.net> wrote:

Are you aware of any suitable mechanism? I=E2=80=99m asking since from my pe=
rspective this clause is mainly intended to allow existing OpenID Connect de=
ployments to use nonce instead of PKCE in combination with OAuth 2.1. It=E2=80=
=99s a compromise. I think we should not encourage others to invent their ow=
n OAuth security mechanisms.=20



                        

                          
On 14. May 2=
020, at 09:37, Nov Matake <matake@gmail.com> wrot=
e:

Hi,

Why not allowing public clients use "other suitable mechanisms=E2=80=9D then=
?
OAuth WG can allow both type of clients do so, then OIDF will define nonce a=
s the alternative only for confidential clients.



                          

                            
2020/05/1=
4 15:56=E3=80=81Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=
=83=BC=E3=83=AB:

Hi all,

I would also like to thank everybody for the substantial discussion. =20

The proposed change for Section 4.1.2.1 works for me (as already stated). I=E2=
=80=99m not fully comfortable with the proposed change for Section 9.7 for t=
he following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE in=
stead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don=E2=80=99t feel comfortable with r=
ecommending any mechanism that this WG is not responsible for and thus did n=
ot conduct the security threat analysis for. I think the better way for us a=
s WG is to define the extension point for other mechanisms. The OpenID Found=
ation (or any other body) can then fill in and issue a statement that nonce (=
or another suitable mechanism) fulfils the requirements of the extension poi=
nt.=20

Based on this considerations, I propose the following text for Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. Public clients MUST use the=20
"code_challenge=E2=80=9D with a transaction-specific value that is securely=20=

bound to the client and the user agent in which the transaction was=20
started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=9D i=
n the=20
same way or other suitable mechanisms to mitigate authorization code=20
injection.

This text follows the logic in Section 4.1.2.1 and allows use of the nonce f=
or confidential clients.

best regards,
Torsten.=20



                            

                              
On 12. M=
ay 2020, at 02:21, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

That works for me.  Thanks all for the useful back-and-forth that got us to t=
his point of clarity.  I suspect many of us learned things along the way; I k=
now that I did!

                                                    Cheers,
                                                    -- Mike

From: Aaron Parecki <aaron@parecki.com>
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com><=
/a>; Mike Jones=20
<Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also upd=
ate section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. The use of the=20
`code_challenge` parameter is RECOMMENDED to this end. For=20
confidential clients, the OpenID Connect `nonce` parameter and ID=20
Token Claim {{OpenID}} MAY be used instead of or in addition to the=20
`code_challenge` parameter for this purpose. The `code_challenge`=20
or OpenID Connect `nonce` value MUST be transaction-specific and=20
securely bound to the client and the user agent in which the transaction was=
 started.

This change better clarifies the specific circumstances under which the "non=
ce" parameter is sufficient to protect against authorization code injection.=


Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden <n=
eil.madden@forgerock.com> wrote:
I am happy with this proposed wording. Thanks for updating it.

=E2=80=94 Neil


On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.=
com> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20

We would like to propose the following text, which is a slight variation fro=
m the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ie=
tf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins wit=
h "If the client does not send the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clients, an=
d MUST reject such requests from other clients unless there is reasonable as=
surance that the client mitigates authorization code injection in other ways=
. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0 a=
nd 2.1 clients simultaneously. The change from Neil's text is the clarificat=
ion of which threats, and changing to MUST instead of SHOULD. The "MUST...un=
less" is more specific than "SHOULD", and since we are already describing th=
e explicit exception to the rule, it's more clear as a MUST here.

Aaron Parecki




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

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


                            

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


                          

                        

                      

                      
_______________=
________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth


                    

                    


                    

                  

                  _______________________________________________

                  OAuth mailing list

                  OAuth@ietf.org

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

                

              

            

            

          

        

      

    

    


    

 =20


=

--Apple-Mail-9FB001C3-9474-4336-A965-9A1976FD4F56--


From nobody Tue May 19 02:39:34 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874E03A131F for ; Tue, 19 May 2020 02:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5SUWfp8BNJq for ; Tue, 19 May 2020 02:39:30 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C199B3A09D1 for ; Tue, 19 May 2020 02:39:30 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id f189so14066614qkd.5 for ; Tue, 19 May 2020 02:39:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9FJv3prIs/YyybtW8SOhPv8D3vsX4IiXIFhBaOboCFE=; b=fi+k3yhHUGlR5OeZp0HmeXAZm1ReKEUioKwqLxWouQLBQrPU2MUMotzs6PTjrODSdD F3X2WbH44dDyVtwyCpjLV/HgJIGbP9WD6GLvTOyBJs8gtnrwjq6E8V8aBege/3ACpwyX ChFWlgS2uauE8AafHIKbk5nW3WhMAIIAYvPYxNmvSV3P1Pj+QGdpi6JMKzHAi8uHXLdZ 299MlF99+Itsub+XiDE2TczyHsaTBQW/FbOsRFZOnvDDgvUb9y6EuEyp3YAQyVM1q71E 1gLNUoRNaquaaekwyiII52a5PubFofFgTPyHrgSpI4N8ykQ4Io1R3ooxL/ORgPGkhWCD cI6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9FJv3prIs/YyybtW8SOhPv8D3vsX4IiXIFhBaOboCFE=; b=L29mCPnE8zSF+Z2JQh9twnZp0klLXUmn7++LgOK0obcRudSbq+dHv7SUvuW0idNueU 1TelOhv8OhOl751GAW5dmQoq5X70IPevQvdCrfFc7M4B+6g7hrZ1Ok5oRc0JmlX07nHl 9xu27GZHgD3t5f3K24oL2Bqv+xAHDzc1ca4ur5lbZe0xL+mbTEgO/J4Grs90cn7tSWcp uPIoKupwl5TpQgR/pEI/heUp0WktCYF5QmkpUgDFyxM4TNogQIIvFFfuHEaKSkykMWZD /8JcczGO6TK3Ah+C8aheRIjvvUwIiM970TZIHJ0u7CqQfSmq8CBaSM1bAdOYmNanN0eB FqDQ==
X-Gm-Message-State: AOAM532X1yFnPOP7iYJUdc1ZvSZajKc9Bdttptwbe+GLnbG80XmDJ3kF jPR947nJdcRGwadnQYIM48LZnktZKK6QQYldBQ==
X-Google-Smtp-Source: ABdhPJxhugAOvrX+Il7pb7l83KRx9famZpOSH/vqibO5L3Or/jIcjCCOexjlQpAQ4gELaQsk7cFAC3yhuw1TgxW9UV4=
X-Received: by 2002:a25:bd0b:: with SMTP id f11mr21351100ybk.351.1589881169628;  Tue, 19 May 2020 02:39:29 -0700 (PDT)
MIME-Version: 1.0
References: <158937215806.9148.1182768951394743318@ietfa.amsl.com> 
In-Reply-To: 
From: Filip Skokan 
Date: Tue, 19 May 2020 11:38:51 +0200
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000059d3cd05a5fd0e4c"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 09:39:33 -0000

--00000000000059d3cd05a5fd0e4c
Content-Type: text/plain; charset="UTF-8"

Hello Brian,

can you share the slide deck from yesterday so that we may continue
the discussion on the mentioned open questions here on the list?

Thank you,

Best,
*Filip*


On Wed, 13 May 2020 at 20:43, Brian Campbell  wrote:

> Just wanted to note that there is a newer -01 revision of the document on
> the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>
> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
> wrote:
>
>> The Web Authorization Protocol (oauth) Working Group will hold
>> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna
>> (16:00 to 17:00 UTC).
>>
>> Agenda:
>> DPOP
>> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>>
>> Information about remote participation:
>> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>>
>> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000059d3cd05a5fd0e4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Brian,

can you share the slide de=
ck from yesterday so that we may continue the=C2=A0discussion on the mentio=
ned open questions here on the list?

Thank you,

Best,
Filip


On Wed, 13 May 2020 at 20:43, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org<=
/a>> wrote:
<=
div dir=3D"ltr">Just wanted to note that there is a newer -01 revision of t=
he document on the agenda https://www.ietf.org/id/draft-ietf-oauth=
-dpop-01.html 

On Wed, May 13, 2020 at 6:16 AM IESG Secretary <iesg-secretary@i=
etf.org> wrote:
The Web Authorization Protocol (oauth) Working Group will hold

a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna (=
16:00 to 17:00 UTC).



Agenda:

DPOP

https://tools.ietf.org/html/draft-ietf-oauth-dpo=
p-00



Information about remote participation:

https://ietf.webex.com/iet=
f/j.php?MTID=3Dm2655406e74aa2b4e129a1b91a076f70b



https://mailarchive.ietf.org=
/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/



_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announ=
ce






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
..=C2=A0 If you have received this communication in error, please notify th=
e sender immediately by e-mail and delete the message and any file attachme=
nts from your computer. Thank you._______________________=
________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000059d3cd05a5fd0e4c--


From nobody Tue May 19 03:09:43 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E473A1335 for ; Tue, 19 May 2020 03:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcRjOD7XEWhZ for ; Tue, 19 May 2020 03:09:40 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F133A1330 for ; Tue, 19 May 2020 03:09:40 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id 50so15162130wrc.11 for ; Tue, 19 May 2020 03:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XotAaJKDk4MVKxKtA3c0pTx0R+xnpIQhIT20zvUQ/eg=; b=UHlEzgNH/Efi5007hKikaXny/0zM0MkwUNW9PLyqO/30wkjAWPixUAD4Ldz7WtEqVK ZC0LjOEMbDFLx51zkbI3zwIm/Dq/IIdg887J9t+ICcdcik3chk4H7XCrUIJhAbHyYFgs Oj/AL+HT79yJSFQYqPuwAIbdyZ8+a/chL+DW8SFqq4+QO1OLTzBf55hr3WvIwEzCUJtr OVbqB6kCTf2kWKy6ZGD4xg3OJCeZjqCxfZWyVtt4p7Ea4ijoMLTMq9+8LUKbo67Dem9m IQZ0MziouY0qUb90U8UtteiaVHbS5lHCCoVes9Lk5hYY4t76sXr671C5q1EJ+GJqde0M t3nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XotAaJKDk4MVKxKtA3c0pTx0R+xnpIQhIT20zvUQ/eg=; b=Lt9FZiLolmMiAZznaeUsHrHnWDAMa3O7p2FhFuRtPwwcBohkXU8/Zf7arUIul3pl9+ XDy0GzDrC03Y8bftzdE1Dhp54v0e8XCpvE8sE5+FfdYCNivQ76moRfqmDYDJADP8A/2l 7aqR2OT/wQLAVuLQUNHOBwc+PfhKIFu5h99yzvsoSFrZJ1UuEtFsmvlZto+AaXlulQoc MuCxriaaZUylmBjc5juniVTbM0TfFDAYrVia0Zrl2I4Hq1Bm40/A6pMiYhX4j4swpytQ TzAVar2LocptuwosNc/8eV+fCSW7lw8WOTcVu/4zkurvwkeCPDgJSTEF+ML0zJiLlbNT I18g==
X-Gm-Message-State: AOAM531mCE0xvBbaZJAQWRBj537A4EYJBGjMK93NckowRy1HXK03LxJu eqma3mx/oAjK28DNEm4uuaeGIvnAKWEo6T7AWFI=
X-Google-Smtp-Source: ABdhPJymB/XRQ7ZKEamI+x+anpX79FppZo8/GdjsBUowBlVtdka3qpBhmqQfW6kChYEBdEtruMzTF7SaU0L543HdpWM=
X-Received: by 2002:a5d:6401:: with SMTP id z1mr26508708wru.226.1589882978935;  Tue, 19 May 2020 03:09:38 -0700 (PDT)
MIME-Version: 1.0
References: <158937215806.9148.1182768951394743318@ietfa.amsl.com>  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Tue, 19 May 2020 06:09:27 -0400
Message-ID: 
To: Filip Skokan 
Cc: Brian Campbell , oauth 
Content-Type: multipart/alternative; boundary="00000000000031a89805a5fd7a65"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 10:09:42 -0000

--00000000000031a89805a5fd7a65
Content-Type: text/plain; charset="UTF-8"

Hi Filip,

I have uploaded the slides to the materials page here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop


Regards,
 Rifaat


On Tue, May 19, 2020 at 5:39 AM Filip Skokan  wrote:

> Hello Brian,
>
> can you share the slide deck from yesterday so that we may continue
> the discussion on the mentioned open questions here on the list?
>
> Thank you,
>
> Best,
> *Filip*
>
>
> On Wed, 13 May 2020 at 20:43, Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
>
>> Just wanted to note that there is a newer -01 revision of the document on
>> the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>>
>> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
>> wrote:
>>
>>> The Web Authorization Protocol (oauth) Working Group will hold
>>> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00
>>> Europe/Vienna (16:00 to 17:00 UTC).
>>>
>>> Agenda:
>>> DPOP
>>> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>>>
>>> Information about remote participation:
>>> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>>>
>>> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> IETF-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited...  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and any file
>> attachments from your computer. Thank you.*
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000031a89805a5fd7a65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Filip,

I have uploaded the slides to=
 the materials page here:

=

Regards,
=C2=A0Rifaat
=C2=A0

On Tue, May =
19, 2020 at 5:39 AM Filip Skokan <=
panva.ip@gmail.com> wrote:
Hello Brian,

can you =
share the slide deck from yesterday so that we may continue the=C2=A0discus=
sion on the mentioned open questions here on the list?

=

Thank you,

Best,
=
Filip


On Wed, 13 May 2020 at 20:43, Brian Campb=
ell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Just want=
ed to note that there is a newer -01 revision of the document on the agenda=
 https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html 
<=
/div>
O=
n Wed, May 13, 2020 at 6:16 AM IESG Secretary <iesg-secretary@ietf.org> wrote:<=
br>
The Web Authoriz=
ation Protocol (oauth) Working Group will hold

a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna (=
16:00 to 17:00 UTC).



Agenda:

DPOP

https://tools.ietf.org/html/draft-ietf-oauth-dpo=
p-00



Information about remote participation:

https://ietf.webex.com/iet=
f/j.php?MTID=3Dm2655406e74aa2b4e129a1b91a076f70b



https://mailarchive.ietf.org=
/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/



_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announ=
ce






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
...=C2=A0 If you have received this communication in error, please notify t=
he sender immediately by e-mail and delete the message and any file attachm=
ents from your computer. Thank you.______________________=
_________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000031a89805a5fd7a65--


From nobody Tue May 19 03:40:30 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249563A1369 for ; Tue, 19 May 2020 03:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxMNaL0SErfq for ; Tue, 19 May 2020 03:40:26 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447973A1368 for ; Tue, 19 May 2020 03:40:26 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id s1so14248730qkf.9 for ; Tue, 19 May 2020 03:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to; bh=Sn81VJQPkcAev5iSi9dg86Hlc3xbp0rgAHcflCV6DXw=; b=vJr9mOB8W6lzpVn45/xwWLu9Gkdq6+wgJTW/94I7HEf3qoxIozKmSJdjgYsKmDDUny eyq1hIWitv9kJjy+3OQRUJZQhD6xG5ZZhJ4D25mozfIv2AcM94MPm7iuz3zz0s2b849b vv+uR5f9hI40KRgDfdUaf+kxw3GPtpmRGesbO5p0uZds8Lbvs5wsqWQlqPwkJS81VXFj GvtRjyvmLCkczIyRq3PjaYOGTXlxf7U7mL2J/2ij9spU7aZDdbC/BF883OEGC4OP3f2G 7jRVHWjLrdF4eZCE6cBXKyAtj6p0ah/Qami+TXqWCHm1Npu+IfNpdtwCWE3cdB4qfVJ0 oDGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=Sn81VJQPkcAev5iSi9dg86Hlc3xbp0rgAHcflCV6DXw=; b=KK8AsubfQjgcQ4zFYNAR3uE6U8mc6dolwpqg6ggEPKqbSKXIwHalI/G97iRLopwmK5 WTy7waKzlfFX5aWa2jX/oiYf79SvyT0XxbWk7NnMI6rNCOhKvRfwhLsGysC+UFedU1O7 XbOdlp3RopVZ7g3ypkCHf919cHj35WhHgQW6BJKCZ+bii2B9uItu7oncPBDWQBN9vZdP bnKH53lyeE2CPBGh3M+yvpihAg5DiUljCh4Q56BNUX4OhMdDO8uQmJSVDi9F+ZcYWa+g nBhxzkjQKEXE5o9zt2B/PnwgjQvSiyUe8Vjb5hPxHWsMBM6cZJwFxHME6fAk42ytbAE4 x9Bw==
X-Gm-Message-State: AOAM5308TI2jX+VorSCusrgZDSXxeAZLxg0FwUgwivc4sN1sgnu8a5or c5ZrMwoQt1VULMdw4bideE0rThLLlOFXB1ReQ28mldGDbQ==
X-Google-Smtp-Source: ABdhPJzkRuDgQDdvorcTe5Vyv9CSeyTpXkMMCTRUOqleEQmqAOwHDt9d/6QiFq/Ye7NuEDNHTv/ZAE2WHHPFK+npi0U=
X-Received: by 2002:a37:484c:: with SMTP id v73mr19764029qka.496.1589884824916;  Tue, 19 May 2020 03:40:24 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 May 2020 03:40:24 -0700
From: Dominick Baier 
MIME-Version: 1.0
Date: Tue, 19 May 2020 03:40:23 -0700
Message-ID: 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000003928bf05a5fde8af"
Archived-At: 
Subject: [OAUTH-WG] JAR: JWT typ
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 10:40:28 -0000

--0000000000003928bf05a5fde8af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

This has been brought up before - but no response.

Either I can=E2=80=99t find it - or it is missing. But is the setting the J=
WT typ
explicitly mentioned somewhere?

I think it should to prevent cross JWT confusion.

Thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

--0000000000003928bf05a5fde8af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Hi,=
=C2=A0

<=
/div>
This has bee=
n brought up before - but no response.

Either I can=E2=80=99t find it - or it is missing. But =
is the setting the JWT typ explicitly mentioned somewhere?

I think it should to prevent cross=
 JWT confusion.

Tha=
nks
=E2=80=94=E2=80=94=E2=80=94
Dom=
inick Baier


--0000000000003928bf05a5fde8af--


From nobody Tue May 19 06:21:01 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415EB3A02C1 for ; Tue, 19 May 2020 06:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ7kv10BMYeZ for ; Tue, 19 May 2020 06:19:57 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F723A03FE for ; Tue, 19 May 2020 06:19:57 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id f83so14861965qke.13 for ; Tue, 19 May 2020 06:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=UZ0NHknFQOmb2aaxC13mTx8nw6bpfZIJQ6YQuCZRfEw=; b=r0uuCJsCP3kWQ0//uoLEuVN6EPVw8nppaMq8wwvcSDYHTqDfGnahsJN757ylTMxRnM PeMgQOMdZC2Ro4QmbRSo81vLKsoHrmGLCxaEbEAyinqPsO/FnbjLQQf/w2fSOOKQSVxz rfHdTkqnprBK3AGAvNBd5h1IVSHSqoHU7vauKTBmk70mpDgRjyKIvQp8NGto7N+digVA r2TXhJArXEkjRDFhKBHcB8O0Bhaq7dX2+c8LRAaufyvfmZX6/0FdeanXk5j4qIFVh4pJ mplSByFmtv79ZDmLQW8oPjGtjBADJuaIVfmnlYtiFSt6075NIGSJuza22ozAuU9jWg2M eMkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UZ0NHknFQOmb2aaxC13mTx8nw6bpfZIJQ6YQuCZRfEw=; b=uOhmyFOMZ+VsdWdL1t5uOugOQ6DFJUq+SZRT+jzncMFCFcRPTfIJaveykRn1vUIn9P EIJGW6G96c4pgEGdVdyyWp1DNed7X/xgY6QZCkQSXJFvUhAWfmFwdRKSTS+OTfe6Fh1q 573dXENfDHH3W7KSjIwD58GGSUFHFbwH+20gas62G/RZokWbCGOkaf1nhh5o8aSeUiP2 tyv5USve1egsEqJ96SscxKGsFeYmIej8Lke6LIolE/JXSTfBijFuuqP7QyK8rzKiNeK7 KjE6U3mxXJvbZNMjx3oCKw/yBnSe7fFh4A4NBfPRdEIIDt7DFTJCLD/Savqe1alMEXBJ 2IkQ==
X-Gm-Message-State: AOAM533wweFkVk7Bd48PDm2LHgKUSxu0gc4+0sTr522ablLjVvueucYf fhO5SnUnqWhRYZyS34QDJ0MjtLnD/Iq8Cg7jUpOLrkOOxg==
X-Google-Smtp-Source: ABdhPJy0/X/Qdpdv8mfQCAYNd98gn3hP7Fd26b6AGj/8bHy8188RlCK/ps0FflKlB5czcwXPONiZyMzalaW4I/9iSDs=
X-Received: by 2002:a5b:44d:: with SMTP id s13mr34097756ybp.414.1589894396216;  Tue, 19 May 2020 06:19:56 -0700 (PDT)
MIME-Version: 1.0
From: Filip Skokan 
Date: Tue, 19 May 2020 15:19:18 +0200
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000b7934105a6002205"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 13:20:18 -0000

--000000000000b7934105a6002205
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is a RE: to yesterday's interim meeting discussion, largely related to
the first rollout step where we want to constrain refresh tokens but leave
protected resource access intact.

I'll start off with a case that I hope we can agree is absolutely necessary
for DPoP to solve - that is constraining refresh tokens for browser based
applications. Now, *do we see this as a secondary objective? I think it
should be on par with access token constraining.* SPAs using code flow and
having access to refresh tokens as means against the continuous browser
efforts to cut down on storage access is a real case servers will be
eventually forced to adopt.

Since rollout for DPoP needs to begin with the AS and Client supporting it
(regardless what order i guess) there are going to be instances where the
RS will be supporting both Bearer and DPoP at the same time.

As discussed yesterday, the client shouldn't know/care and change its
behaviour when it comes to using access tokens.

*But what is the client behaviour we take for standard?* Because I can see
two conflicting implementations in the wild

   1. The client echoes the token_type it received from the token endpoint
   as the authorization scheme
      - (optionally) throws on unrecognized token type values
   2. The client uses Bearer as a fixed authorization scheme and ignores
   the token_type it received

#2 is an implementation which I suspect has no idea about DPoP, but if
extended to send DPoP headers (through various mechanism - library
extensions or even manipulating the `XMLHttpRequest` prototype) will

   - =F0=9F=8E=89 get the benefit of having its Refresh Tokens bound
   - =F0=9F=8E=89 most likely continue to work with RSs that only support B=
earer
   - =E2=9D=8C will cease to work with RSs that will adopt support for DPoP=
 because
   it'll be using the wrong scheme, that is unless (=F0=9F=8E=89) RSs suppo=
rting DPoP
   choose to suspend the requirement to use the new scheme and instead depe=
nd
   on the presence of `cnf.jkt` as means to trigger DPoP validation. *Q: is
   that an acceptable thing to do?*

Arguably, client behaviour #1 is what a client should be using if it
supports other schemes besides Bearer. But it may as well be the behaviour
of a client that has no clue about DPoP, right? Again, such client can be
made to support DPoP in a SPA through manipulation of the XMLHttpRequest
prototype, in which case the developer needs to do the same for
the protected resource calls. But at this point the developer has to know
which RS to apply DPoP to and which not - ergo - which to send Bearer vs.
DPoP scheme to? The developer will have to write a whitelist of resource
servers anyway - and there we get to the point where client has information
and functionality that it shouldn't /need to/ have.

Its great that we have token_type, authorization header schemes, etc...,
but we don't seem have a well defined (or at least followed) behaviour for
our clients around handling the token_type response values and their usage.

A developer has to resolve to navigate this monkey course unless the RS
definition on the AS is aware of the fact that the RS does support DPoP, so
that the issued token_type is always correct for the RS. So, *should we
make that a recommended way of 'indicating' when to issue Bearer vs DPoP
access tokens?*

What else could we do that doesn't give more decision making to the clients
so that the very first step - *Refresh Tokens get constrained* - is achieve=
d*
but Protected Resource access is unaffected?*

Note that this was not "a thing" for mTLS because it continues to use the
Bearer scheme (for better or worse) and it completely omits possible
continuous rollout or discussing what are the signals the RS must use to
require mTLS to be used), same for the abandoned OAuth 2.0 Token Binding
draft (also continued to use the Bearer scheme).

I suspect we have just this opportunity to fix token types and their use
and if we can't, we'll have to resolve to abandon that extension point as
one that doesn't support continued rollout of real sender constraining
mechanism (e.g. http signatures in the future) and just continue using
Bearer because in the end, given that RSs could be relying on the presence
of the cnf claim to figure out the token's constraining mechanism, would
that be such a bad thing?

Put it the other way around. By introducing Bearer scheme, do we actually
gain anything of value that can't be gained through other means?

Note that this message didn't start with the goal of questioning the new
scheme use, it just sort of landed there... My pedantic nature would love
to see the new scheme and token_type extension point used as it was meant
to be but I also recognize the many issues it brings that could be
sidestepped by not introducing it in the first place, all without losing
capabilities.

Previous material on the topic

   - https://github.com/danielfett/draft-dpop/issues/41, decision to break
   backwards compatibility amongst the authors
   - ML
   
thread,
   in my opinion inconclusive, no consensus


S pozdravem,
*Filip Skokan*

--000000000000b7934105a6002205
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This is a RE: to yesterday's interim meeting disc=
ussion, largely related to the first rollout step where we want to constrai=
n refresh tokens but leave protected resource access intact.
=

I'll start off with a case that I hope we can agree=C2=
=A0is absolutely necessary for DPoP to solve - that is constraining refresh=
 tokens for browser based applications. Now, do we see this as a seconda=
ry objective? I think it should be on par with access token constraining.=C2=A0SPAs using code flow and having access to refresh tokens as means a=
gainst the continuous browser efforts to cut down on storage access is a re=
al case servers will be eventually forced to adopt.

Since rollout for DPoP needs to begin with the AS and Client supporting i=
t (regardless what order i guess) there are going to be instances where the=
 RS will be supporting both Bearer and DPoP at the same time.
As discussed yesterday, the client shouldn't know/care and =
change its behaviour when it comes to using access tokens.

But what is the client behaviour we take for standard? Beca=
use I can see two conflicting implementations in the wild
    The client echoes the token_type it received from the token endpoint as th=
e authorization scheme
    • (optionally) throws on unrecognized toke=
n type values
  1. The client uses Bearer as a fixed authorization =
scheme and ignores the token_type it received
#2 is an implem=
entation which I suspect has no idea about DPoP, but if extended to send DP=
oP headers (through various mechanism - library extensions or even manipula=
ting the `XMLHttpRequest` prototype) will
  • =F0=9F=8E=89 ge=
t the benefit of having its Refresh Tokens bound
  • =F0=9F=8E=89 most =
likely continue to work with RSs that only support Bearer
  • =E2=9D=8C=
 will cease to work with RSs that will adopt support for DPoP because it=
9;ll be using the wrong scheme, that is unless (=F0=9F=8E=89) RSs supportin=
g DPoP choose to suspend the requirement to use the new scheme and instead =
depend on the presence of `cnf.jkt` as means to trigger DPoP validation. Q: is that an acceptable thing to do?
Arguably, cl=
ient behaviour #1 is what a client should be using if it supports other=C2=
=A0schemes besides Bearer. But it may as well be the behaviour of a client =
that has no clue about DPoP, right? Again, such client can be made to suppo=
rt DPoP in a SPA through manipulation of the=C2=A0XMLHttpRequest prototype,=
 in which case the developer needs to do the same for the=C2=A0protected re=
source calls. But at this point the developer has to know which RS to apply=
 DPoP to and which not - ergo - which to send Bearer vs. DPoP scheme to? Th=
e developer will have to write a whitelist of resource servers anyway - and=
 there we get to the point where client has information and functionality t=
hat it shouldn't /need to/ have.

Its gre=
at that we have token_type, authorization header schemes, etc..., but we do=
n't seem have a well defined (or at least followed) behaviour for our c=
lients around handling the token_type response values and their usage.

A developer has to resolve to navigate this monkey cou=
rse unless the RS definition on the AS is aware of the fact that the RS doe=
s support=C2=A0DPoP, so that the issued token_type is always correct for th=
e RS. So, should we make that a recommended way of 'indicating' =
when to issue Bearer vs DPoP access tokens?

=

What else could we do that doesn't give more decision making to th=
e clients so that the very first step -=C2=A0Refresh Tokens get constrai=
ned=C2=A0- is achieved but Protected Resource access is unaffected?<=
/b>

Note that this was not "a thing&qu=
ot; for mTLS because it continues to use the Bearer scheme (for better or w=
orse) and it completely=C2=A0omits possible continuous rollout or discussin=
g what are the signals the RS must use to require mTLS to be used), same fo=
r the abandoned OAuth 2.0 Token Binding draft (also continued to use the Be=
arer scheme).=C2=A0

I suspect we have just this op=
portunity to fix token types and their use and if we can't, we'll h=
ave to resolve to abandon that extension point as one that doesn't supp=
ort continued rollout of real sender constraining mechanism (e.g. http sign=
atures in the future) and just continue using Bearer because in the end, gi=
ven that RSs could be relying on the presence of the cnf claim to figure ou=
t the token's constraining mechanism, would that be such a bad thing?

Put it the other way around. By introducing Bearer =
scheme, do we actually gain anything of value that can't be gained thro=
ugh other means?

Note that this message didn't=
 start with the goal of questioning the new scheme use, it just sort of lan=
ded there... My pedantic nature would love to see the new scheme and token_=
type extension point used as it was meant to be but I also recognize the ma=
ny issues it brings that could be sidestepped by not introducing it in the =
first place, all without losing capabilities.

Prev=
ious material on the topic

S poz=
dravem,
Filip Skokan


--000000000000b7934105a6002205--


From nobody Tue May 19 09:14:11 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62E3A0AA6 for ; Tue, 19 May 2020 09:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwrbFPXRJWlg for ; Tue, 19 May 2020 09:14:06 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650101.outbound.protection.outlook.com [40.107.65.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 6EBBA3A0AC5 for ; Tue, 19 May 2020 09:14:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kt+4cTkNke9MrXAJymfOC74tjKUjXiWY6l538SoSsssPHw/Nb8wtqH4wLEId1q5BHdTsqlBTen/UDUtMx9XV1OdtmA9a2jhDhNpYVNqmckgFHgwNPlN7dAU9/GTynDGnnhZEogPOEk2s2HBCS4LUps5YcyeMSx2Df7ssXtx4pZzWD51/Ljys25GVcmkrONLDcgx4ao43Eag5rNLewt9x7YY4/f0uJkN9AFSMQUU8ypU5mME3JfCh+96VmyOdd0bS3vujzGT1AprjO01VWWWq76jUql0y+9JpcwLs8D7eJ5I1VwU4kDo8z7Xwb3/i7aP8EFzzwxHWpoQLevBLYPfCnQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M1pylTxaTEXLYPr1FaC94YBjGBc8yjf474i7u9cn9Fs=; b=KsTOawj8viOC6426Qw4t4zinXTAlMhPrgZAFn7awCAJ60Sf4NTsjPMU0JfQg3AFtCTD7Pr5gVUwbIEyhab0cK4tAugQQE2DnFaaoc5JhoW55xBxpW7c2hJO6QqdJDDcu5F8vKrdAbsbd/WKyRc4BcrBowv69bSYVE+daIXAVY6zZ+a9yFzDu72u41JYORgyeo159tgxcEUCiX31yPUVF7XRE1GOIBMQYGK5FchcTw0VeFXgkLzc+BsMHcq2AIBg574oTCcjulblM1H3iYZs95SdsAII7J8AIZn/wOq4No5s/A0wgbOxzXuTOTF2s9P8/S06eBXgCS3zAZyxIGRwD+A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M1pylTxaTEXLYPr1FaC94YBjGBc8yjf474i7u9cn9Fs=; b=HP0MvNXiYO5bb4A3zEvF71ZqFwyEdub3ZhjA6d6qcbKIag09CDuYyw6tpcJbwf1V981JQHSVUXmw+KWYNzGaEbRdRIsWQnx+eoDa8Rv8t7ArP9+PpeRHrvSWeL2Bz4u3zrpkQayU7xfylH284gnMFPp2CXQ5Mux4JB7UVslCRJ0=
Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0834.namprd00.prod.outlook.com (2603:10b6:208:1cc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3061.0; Tue, 19 May 2020 16:13:53 +0000
Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::987e:8a03:43ba:8ad2]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::987e:8a03:43ba:8ad2%6]) with mapi id 15.20.3060.000; Tue, 19 May 2020 16:13:53 +0000
From: Mike Jones 
To: Nov Matake , Daniel Fett 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
Thread-Index: AdYt+Hgi6C49zluNRV+Y2W1Ic4YJWg==
Date: Tue, 19 May 2020 16:13:53 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=de4e8208-fc68-4aca-9e8c-00004ceff259; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-19T16:12:01Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 62cff067-f728-4aea-cf58-08d7fc0f9ff6
x-ms-traffictypediagnostic: BL0PR00MB0834:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 040866B734
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vsToT4owi4y5mKzndVNMSA1uhf2hzqnC15FuDQKgRsAzQPFzMa0hcr8qlJ/0JFs+Cu3d77x0yGAssVkotNHaHBI7n9RYjBtaxCSh+QaqGLkbGNwwWTNR3W/W9Wh9bOyHZ2O3iA3XhbgxeXybEdNqfM1Hhd4DUWFHw0ANBr9Y93VnsAGA2WgiwNL71PAg/1qClYdsZPjrQkkEYPGkRrkXeFsqh0Vw8443AWqxVYcQM7C6tAJtMZsNTp8b9bdVQp9xolX23XM/MAXGquTG9uWGl9rqJM9u/L33Y5Hl7jPDJQXfpEQyDSSYi0Xi83Mj8UakqqaoNhQ+8gk9vx0DRZGV0iA66axqmNq5ciFUmGKQNgeCjMK17/PuTSEadxb2giCZSPi9rxeYLvLRfIPHVW1aag==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39860400002)(376002)(396003)(136003)(366004)(346002)(8936002)(8990500004)(9686003)(166002)(71200400001)(55016002)(66574014)(8676002)(10290500003)(33656002)(478600001)(30864003)(83080400001)(82960400001)(966005)(82950400001)(66946007)(66476007)(66556008)(64756008)(66446008)(4326008)(76116006)(52536014)(7696005)(86362001)(26005)(2906002)(5660300002)(316002)(110136005)(186003)(53546011)(6506007); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: Rrsva2ZKu8bOy0GFizOmLhr72/soxwYa+fNsA4PgVv+rTs93Mdw4/XFR8d0pU7g+HX7sT1PHO+BHq0NuBvldGbgZvzFmQ5ZPBL+mZAUrkOIVwsFVHT+kfCenWm35LzcMJh6W4GCpu+SJFkb1NZMLg9CnR5MN3G6rJwOgZjCkEhaynnG/BdDKFBzZfjP6pnwuSHzPLMG2MtSYjwgylLENLA+OyWgLu8TgJEOsDMOFUHMC/Oe0C0Mt46uTYLmqcLN1k11is41FkOq5vMuEqXuuc7fxGUgjIkCHbLvHhze2ZyZbUJAsglLSSxwalKCA9LctYEQCGGnYKpbT2Z/Xwr+db73Jl4XtaCN4CrKZdrmKmPJAbCwtzZpHw4M472UMQCYlH6LzpFsnbAXLLB0XO4BLSLIqkIduf+834pJMr2mHjmPsQB2Cp+ipdxHQ3r0XVxudCWvyvlftRburCoEck3waz94qoAGpmcSc925cFXWDEEE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688FA432C1351809AAABF24F5B90MN2PR00MB0688namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 62cff067-f728-4aea-cf58-08d7fc0f9ff6
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2020 16:13:53.3441 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ajlo4LGjBB0vZEMdcZpwWsabx10XLMqyqoxr2xLUYaerS/xAibqm7twDTGWDHO3wJ39Bl5ZwX7WehwR79XMn3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0834
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 16:14:10 -0000

--_000_MN2PR00MB0688FA432C1351809AAABF24F5B90MN2PR00MB0688namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U28gaXQgc291bmRzIG1lIGxpa2UgdGhlIGZpeCBpcyB0byBoYXZlIHNlcnZlcnMgcmVqZWN0IFBL
Q0UgcmVxdWVzdHMgd2l0aCBpbmNvbXBsZXRlIHBhcmFtZXRlciBzZXRzOiByZXF1ZXN0cyB0aGF0
IG9ubHkgY29udGFpbnMgb25lIG9mIGNvZGVfY2hhbGxlbmdlIGFuZCBjb2RlX3ZlcmlmaWVkLiAg
V2lsbCB0aGF0IGVsaW1pbmF0ZSB0aGUgYXR0YWNrLCBOb3Y/DQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9B
dXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTm92IE1hdGFrZQ0KU2Vu
dDogTW9uZGF5LCBNYXkgMTgsIDIwMjAgMTE6NTAgUE0NClRvOiBEYW5pZWwgRmV0dCA8ZmV0dEBk
YW5pZWxmZXR0LmRlPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSBwcm9wb3NlZCByZXNvbHV0aW9uIGZvciBQS0NFIGluIE9BdXRoIDIuMQ0KDQpTdXJlLCBmZWVs
IGZyZWUgdG8gYWRkIHRoZSBzZW5hcmlvIHRvIHlvdXIgcG9zdC4NCg0KRllJOg0KbXkgT0F1dGgy
IHNlcnZlciBydWJ5IGdlbSByZWplY3RzIHN1Y2ggdG9rZW4gcmVxdWVzdHMsDQpodHRwczovL2dp
dGh1Yi5jb20vbm92L3JhY2stb2F1dGgyL2Jsb2IvbWFzdGVyL2xpYi9yYWNrL29hdXRoMi9zZXJ2
ZXIvZXh0ZW5zaW9uL3BrY2UucmIjTDI4DQphbmQgR29vZ2xlIGFsc28gZG9lcyB0aGUgc2FtZS4N
Cmh0dHBzOi8vZ2lzdC5naXRodWIuY29tL25vdi85ZmViYTg2Njg1YmQzYjE4YjRiZjdiZmI4ODAy
MjA0Ng0KDQpTbyBJJ20gZ3Vlc3Npbmcgc3VjaCBiZWhhdmlvciBpcyByZWxhdGl2ZWx5IHJhcmUt
Y2FzZSwgaG9wZWZ1bGx5Lg0KDQppUGFk44GL44KJ6YCB5L+hDQoNCg0KMjAyMC8wNS8xOSAxNTo0
M+OAgURhbmllbCBGZXR0IDxmZXR0QGRhbmllbGZldHQuZGU8bWFpbHRvOmZldHRAZGFuaWVsZmV0
dC5kZT4+44Gu44Oh44O844OrOg0K77u/DQpIaSwNCg0KQW0gMTkuMDUuMjAgdW0gMDQ6NTUgc2No
cmllYiBOb3YgTWF0YWtlOg0KSSB0aG91Z2h0IHRoZSBzZXJ2ZXIgTVVTVCByZWplY3Qgc3VjaCB0
b2tlbiByZXF1ZXN0cywgYnV0IEkgY291bGRu4oCZdCBmaW5kIHN1Y2ggZGVmaW5pdGlvbiBpbiBS
RkM3NjM2Li4uDQoNCj4gVGhlIGNsaWVudCB3aWxsIHNlbmQgdGhlIGNvZGUsIGFsb25nIHdpdGgg
YSAobm93IG5vdCBtYXRjaGluZykgY29kZV92ZXJpZmllciB0byB0aGUgc2VydmVyLiBUaGUgc2Vy
dmVyIHdpbGwgaWdub3JlIHRoZSBjb2RlX3ZlcmlmaWVyIChhcyBpdCB3YXMgbm90IGV4cGVjdGVk
KSBhbmQgc2VuZCBiYWNrIGFuIGFjY2VzcyB0b2tlbiBhbmQgSUQgdG9rZW4gdG8gdGhlIGNsaWVu
dC4NCmh0dHBzOi8vZGFuaWVsZmV0dC5kZS8yMDIwLzA1LzE2L3BrY2UtdnMtbm9uY2UtZXF1aXZh
bGVudC1vci1ub3QvI25vbmNlcGtjZS1zaWRlc3RlcC1hdHRhY2sNCg0KSWYgdGhlIGJlaGF2aW9y
IGlzIGFjY2VwdGFibGUgYnkgUkZDNzYzNiwgIk5vbmNlL1BLQ0UgU2lkZXN0ZXAgQXR0YWNr4oCd
IHdvdWxkIGJlIHBvc3NpYmxlLg0KDQpJICp0aGluayogdGhhdCB0aGVyZSBpcyBub3RoaW5nIHBy
ZXZlbnRpbmcgc2VydmVycyBmcm9tIHNvbWV0aW1lcyB1c2luZyBQS0NFIGFuZCBzb21ldGltZXMg
dXNpbmcgTm9uY2UuIEkgYXNzdW1lIHRoYXQgdGhpcyBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRo
ZSBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy4NCg0KSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGhl
YXIgaG93IGFjdHVhbCBpbXBsZW1lbnRhdGlvbnMgaGFuZGxlIHRoaXMgaW4gcHJhY3RpY2UuDQoN
ClBsdXMsIHdpdGggc3VjaCBBUyBiZWhhdmlvciwgQ1NSRiBwcm90ZWN0aW9uIHVzaW5nIFBLQ0Ug
Y2FuIGFsc28gYmUgYnlwYXNzZWQgYXMgYmVsb3cuDQoxLiBUaGUgYXR0YWNrZXIgcmVtb3ZlcyBj
b2RlX2NoYWxsZW5nZSBmcm9tIGhpcy9oZXIgb3duIEF1dGhaIFJlcSwgcmVjZWl2ZXMgYSBub24t
Y29kZV9jaGFsbGVuZ2UtYm91bmQgY29kZSwgYW5kIHNlbmRzIGl0IHRvIHRoZSB2aWN0aW0uDQoy
LiBUaGUgY2xpZW50IHJlY2VpdmVzIHRoZSBhdHRhY2tlcuKAmXMgY29kZSBmcm9tIHRoZSB2aWN0
aW0sIGFuZCBzZW5kcyBpdCB0byB0aGUgQVMgdy8gdGhlIHZhbGlkIGNvZGVfdmVyaWZpZXIgYm91
bmQgdG8gdGhlIHZpY3RpbeKAmXMgYnJvd3NlciBzZXNzaW9uLg0KMy4gVGhlIEFTIGlnbm9yZXMg
dGhlIGNvZGVfdmVyaWZpZXIgYW5kIHJldHVybnMgdG9rZW5zLg0KDQpJZiB0aGF04oCZcyB0aGUg
Y2FzZSwgY3VycmVudCBPQXV0aCAyLjAgUEtDRSBpbXBsZW1lbnRhdGlvbiBjYW4gYmUgd2Vha2Vy
IHRoYW4gZXhwZWN0ZWQuLg0KDQpFeGNlbGxlbnQgcG9pbnQhDQoNCldvdWxkIGl0IGJlIG9rYXkg
aWYgSSBhZGQgdGhhdCBhdHRhY2sgdG8gdGhlIG9yaWdpbmFsIHBvc3QgKHdpdGggY3JlZGl0cywg
b2YgY291cnNlKT8NCg0KLURhbmllbA0KDQpub3YNCg0KDQoyMDIwLzA1LzE5IDE6NTTjgIFEYW5p
ZWwgRmV0dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPG1haWx0bzpmZXR0QGRhbmllbGZldHQuZGU+PuOB
ruODoeODvOODqzoNCg0KSGkgYWxsLA0KDQpUYWxraW5nIHRvIFRvcnN0ZW4sIHdlIHJlYWxpemVk
IHRoYXQgcHJvdmlkaW5nIGEgZ2VuZXJpYyBleHRlbnNpb24gcG9pbnQgaGVyZSBpcyBwcm9iYWJs
eSBub3QgYSBnb29kIGlkZWEuIEl0IGlzIHJlYWxseSBoYXJkIHRvIHRlbGwgd2hhdCBwcm90ZWN0
cyB5b3UgZnJvbSBjb2RlIGluamVjdGlvbiBhbmQgd2hhdCBkb2VzIG5vdCwgYW5kIHBlb3BsZSBt
aWdodCBjb21lIHVwIHdpdGggYWxsIHNvcnRzIG9mIG5vbi1zdGFuZGFyZCBhbmQgcG90ZW50aWFs
bHkgaW5zZWN1cmUgc29sdXRpb25zLg0KDQpFdmVuIGp1c3QgZm9yIFBLQ0UgdnMuIE5vbmNlLCBp
dCBpcyBub3Qgb2J2aW91cyBpZiB0aGV5IHByb3ZpZGUgdGhlIHNhbWUgbGV2ZWwgb2YgcHJvdGVj
dGlvbi4gSW4gYW4gYXR0ZW1wdCB0byBhbnN3ZXIgdGhpcyBxdWVzdGlvbiwgSSB0cmllZCB0byBj
b21lIHVwIHdpdGggYSBtb3JlIHN5c3RlbWF0aWMgYW5hbHlzaXMgb2YgIlBLQ0UgdnMgTm9uY2Ui
LiBJIHdyb3RlIHVwIG15IHJlc3VsdHMgaGVyZToNCmh0dHBzOi8vZGFuaWVsZmV0dC5kZS8yMDIw
LzA1LzE2L3BrY2UtdnMtbm9uY2UtZXF1aXZhbGVudC1vci1ub3QvDQoNCkFsdGhvdWdoIHRoaXMg
aXMgbm90IGEgZm9ybWFsIGFuYWx5c2lzLCBJIGhvcGUgdGhhdCBJIGhhdmUgY292ZXJlZCBhbGwg
aW50ZXJlc3RpbmcgY2FzZXMuIFBsZWFzZSByZXZpZXcgdGhlIHRleHQgYW5kIGxldCBtZSBrbm93
IGlmIEkgaGF2ZSBtaXNzZWQgc29tZXRoaW5nIG9yIGlmIHRoZXJlIGFyZSBhbnkgbWlzdGFrZXMu
DQoNClRoZSBtYWluIHJlc3VsdHMgYXJlOg0KDQogIDEuICBJbiB0ZXJtcyBvZiBwcm90ZWN0aW9u
IGFnYWluc3QgQ1NSRiBhbmQgY29kZSBtaXN1c2UsIFBLQ0UgYW5kIE5vbmNlIHByb3ZpZGUgc2lt
aWxhciBsZXZlbHMgb2Ygc2VjdXJpdHksIHdpdGggYSBzbGlnaHQgYWR2YW50YWdlIGZvciBQS0NF
Lg0KICAyLiAgSW4gcHJhY3RpY2UsIGEgY2lyY3VtdmVudGlvbiBvZiBib3RoIG1lY2hhbmlzbXMs
IGhvd2V2ZXIsIGlzIHBvc3NpYmxlIGlmIGFuIEFTIGFsbG93cyBhIGNsaWVudCB0byBjaG9vc2Ug
YmV0d2VlbiBQS0NFIGFuZCBOb25jZSBhbmQgdGhlIGNsaWVudCBtYWtlcyB1c2Ugb2YgdGhpcyBm
cmVlZG9tLiBJIHByb3Bvc2UgdG8gY2FsbCB0aGlzIGF0dGFjayB0aGUgTm9uY2UvUEtDRSBTaWRl
c3RlcCBBdHRhY2suIOKGkiBQbGVhc2UgcmV2aWV3IHRoZSBhdHRhY2sgZGVzY3JpcHRpb24gaW4g
dGhlIGFuYWx5c2lzLg0KICAzLiAgVG8gYXZvaWQgdGhlIE5vbmNlL1BLQ0UgU2lkZXN0ZXAgQXR0
YWNrLCBjbGllbnRzIG11c3Qgbm90IHN3aXRjaCBiZXR3ZWVuIHVzaW5nIG9ubHkgUEtDRSBhbmQg
b25seSBOb25jZSAoYnV0IG1heSB1c2UgYm90aCBpbiBwYXJhbGxlbCwgb3Igc3dpdGNoIGJldHdl
ZW4gdXNpbmcgb25seSBQS0NFIGFuZCBQS0NFK05vbmNlKS4gQXV0aG9yaXphdGlvbiBzZXJ2ZXJz
IG11c3QgZW5mb3JjZSBQS0NFIHVubGVzcyB0aGV5IGtub3cgdGhhdCB0aGUgY2xpZW50IHVzZXMg
Tm9uY2UgZm9yIGFsbCBvZiBpdHMgZmxvd3MgKGFuZCBjaGVja3MgdGhlIE5vbmNlIHZhbHVlKS4g
VGhlIHByZXNlbmNlIG9mIGEgbm9uY2UgcGFyYW1ldGVyIGluIHRoZSBhdXRob3JpemF0aW9uIHJl
cXVlc3QgaXMgbm90IHN1ZmZpY2llbnQgdG8gZGV0ZXJtaW5lIGlmIGEgY2xpZW50IGFjdHVhbGx5
IGNoZWNrcyB0aGUgbm9uY2UgY2xhaW0gaW4gdGhlIElEIHRva2VuLg0KQXMgeW91IGNhbiBzZWUs
IGFscmVhZHkgaGF2aW5nIHR3byBtb3JlLW9yLWxlc3Mgd2VsbC11bmRlcnN0b29kIG1lY2hhbmlz
bXMgaXMgaGFyZCBlbm91Z2ggdG8gd3JhcCB5b3VyIGhlYWQgYXJvdW5kIGZyb20gYSBzZWN1cml0
eSBzdGFuZHBvaW50LiBXZSBzaG91bGQgdGhlcmVmb3JlIG1ha2UgUEtDRSB0aGUgZGVmYXVsdCBh
bmQgTm9uY2UgYW4gb3B0aW9uIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4NClRvIHRoaXMg
ZW5kLCBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbHdpbmcgc3RyYXdtYW4sIGJhc2Vk
IG9uIFRvcnN0ZW4ncyBhbmQgQWFyb24ncyBzdWdnZXN0aW9uczoNCkFuIEFTIE1VU1QgcmVqZWN0
IHJlcXVlc3RzIHdpdGhvdXQgYSBjb2RlX2NoYWxsZW5nZSBmcm9tIHB1YmxpYw0KY2xpZW50cywg
YW5kIE1VU1QgcmVqZWN0IHN1Y2ggcmVxdWVzdHMgZnJvbSBvdGhlciBjbGllbnRzIHVubGVzcyB0
aGVyZQ0KaXMgcmVhc29uYWJsZSBhc3N1cmFuY2UgdGhhdCB0aGUgY2xpZW50IG1pdGlnYXRlcyBh
dXRob3JpemF0aW9uIGNvZGUNCmluamVjdGlvbiB1c2luZyB0aGUgT3BlbklEIENvbm5lY3QgTm9u
Y2UgbWVjaGFuaXNtIGFuZCB0aGF0IHRoaXMNCm1pdGlnYXRpb24gaXMgdXNlZCBmb3IgYWxsIGlu
dGVyYWN0aW9ucyB3aXRoIHRoZSBjbGllbnQuIFNlZSBzZWN0aW9uDQo5LjcgZm9yIGRldGFpbHMu
DQoNClNlY3Rpb24gOS43Og0KDQpDbGllbnRzIE1VU1QgcHJldmVudCBpbmplY3Rpb24gKHJlcGxh
eSkgb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBpbnRvDQp0aGUgYXV0aG9yaXphdGlvbiByZXNwb25z
ZSBieSBhdHRhY2tlcnMuIFRoZSB1c2Ugb2YgdGhlDQpgY29kZV9jaGFsbGVuZ2VgIHBhcmFtZXRl
ciBpcyBSRUNPTU1FTkRFRCB0byB0aGlzIGVuZC4gRm9yDQpjb25maWRlbnRpYWwgY2xpZW50cywg
dGhlIE9wZW5JRCBDb25uZWN0IGBub25jZWAgcGFyYW1ldGVyIGFuZCBJRA0KVG9rZW4gQ2xhaW0g
e3tPcGVuSUR9fSBNQVkgYmUgdXNlZCBpbnN0ZWFkIG9mIG9yIGluIGFkZGl0aW9uIHRvIHRoZQ0K
YGNvZGVfY2hhbGxlbmdlYCBwYXJhbWV0ZXIgZm9yIHRoaXMgcHVycG9zZS4gVGhlIGBjb2RlX2No
YWxsZW5nZWAgb3INCk9wZW5JRCBDb25uZWN0IGBub25jZWAgdmFsdWUgTVVTVCBiZSB0cmFuc2Fj
dGlvbi1zcGVjaWZpYyBhbmQgc2VjdXJlbHkNCmJvdW5kIHRvIHRoZSBjbGllbnQgYW5kIHRoZSB1
c2VyIGFnZW50IGluIHdoaWNoIHRoZSB0cmFuc2FjdGlvbiB3YXMNCnN0YXJ0ZWQuDQoNCklmIHRo
ZSBPcGVuSUQgQ29ubmVjdCBgbm9uY2VgIGlzIHVzZWQgdG8gbWl0aWdhdGUgYXV0aG9yaXphdGlv
biBjb2RlDQppbmplY3Rpb24gaW5zdGVhZCBvZiBgY29kZV9jaGFsbGVuZ2VgLCBjbGllbnQgYW5k
IGF1dGhvcml6YXRpb24gc2VydmVyDQpNVVNUIGVuc3VyZSB0aGF0IHRoZSBtaXRpZ2F0aW9uIGlz
IGFwcGxpZWQgdG8gZXZlcnkgaW50ZXJhY3Rpb24gd2l0aA0KdGhlIGNsaWVudCBhbmQgdGhhdCB0
aGUgY2xpZW50IGNhbm5vdCBzd2l0Y2ggYmV0d2VlbiBgY29kZV9jaGFsbGVuZ2VgDQphbmQgYG5v
bmNlYC4gRm9yIGV4YW1wbGUsIHRoZSBwcmVzZW5jZSBvZiBhIGBub25jZWAgcGFyYW1ldGVyIGlu
IHRoZQ0KYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIG5vdCBzdWZmaWNpZW50IHRvIGRldGVybWlu
ZSB0aGF0IHRoZQ0KYGNvZGVfdmVyaWZpZXJgIGNoZWNrIGNhbiBiZSBza2lwcGVkLg0KDQpPZiBj
b3Vyc2UsIHdlIG5lZWQgdG8gYWRhcHQgdGhlIHdvcmRpbmcgaW4gdGhlIFNlY3VyaXR5IEJDUCBh
Y2NvcmRpbmdseS4NCi1EYW5pZWwNCg0KDQpBbSAxNS4wNS4yMCB1bSAwMTowMSBzY2hyaWViIE1p
a2UgSm9uZXM6DQoNCkkgYWdyZWUgd2l0aCBOb3YgdGhhdCBvYnNjdXJpbmcgdGhlIGxhbmd1YWdl
IGluIDkuNyB3b3VsZCBiZSBhIGRpc3NlcnZpY2UgdG8gZGV2ZWxvcGVycy4NCg0KDQoNClRoZSBT
ZWN1cml0eSBCQ1AsIHdoaWNoIGhhcyBhbHJlYWR5IGdvaW5nIHRoZSBXR0xDLCBleHBsaWNpdGx5
IGNhbGxzIG91dCB0aGUgdXNlIG9mIG5vbmNlIGFzIHBhcnQgb2YgdGhlIGJlc3QgcHJhY3RpY2Vz
LiAgT0F1dGggMi4xIHNob3VsZCBkbyBubyBsZXNzLg0KDQoNCg0KVGhlIDkuNyBsYW5ndWFnZSB0
aGF0IEFhcm9uIHByb3Bvc2VkIHdhcyB0aGUgcmVzdWx0IG9mIG1hbnkgcGVvcGxlJ3MgY29udHJp
YnV0aW9ucyBhbmQgYSB2aWdvcm91cyBkaXNjdXNzaW9uLiAgTGV0J3MgcHVibGlzaCB0aGUgbmV4
dCB2ZXJzaW9uIG9mIDIuMSB3aXRoIHRoYXQgbGFuZ3VhZ2UgaW50YWN0LCBhcyBJIGJlbGlldmUg
aXQgcmVwcmVzZW50cyBhdCBsZWFzdCBhIGxvY2FsIHBvaW50IG9mIGhhcmQtd29uIGNvbnNlbnN1
cy4gIExldCdzIGdldCB0aGF0IGxhbmd1YWdlIGludG8gdGhlIHJlY29yZCBvZiBkcmFmdHMuDQoN
Cg0KDQpUaGVyZSdzIGFsd2F5cyB0aW1lIHRvIGRlYmF0ZSBpdCBhbmQgY2hhbmdlIGl0IGxhdGVy
IGluIHN1YnNlcXVlbnQgZHJhZnRzLCBidXQgbGV0J3Mgbm90IG5vdyBsb3NlIHdoYXQgaXQgdG9v
ayBhIGxvdCBvZiBlZmZvcnQgdG8gYWNoaWV2ZS4NCg0KDQoNCiAgICBUaGFua3MsDQoNCiAgICAt
LSBNaWtlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOb3YgTWF0
YWtlIDxtYXRha2VAZ21haWwuY29tPjxtYWlsdG86bWF0YWtlQGdtYWlsLmNvbT4NCg0KU2VudDog
VGh1cnNkYXksIE1heSAxNCwgMjAyMCAzOjE4IEFNDQoNClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0
IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD48bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0
Pg0KDQpDYzogT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVs
LkpvbmVzQG1pY3Jvc29mdC5jb20+DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHByb3Bvc2Vk
IHJlc29sdXRpb24gZm9yIFBLQ0UgaW4gT0F1dGggMi4xDQoNCg0KDQpUaGVyZSBpcyBubyBzcGVj
aWZpYyBtZWNoYW5pc20gcmlnaHQgbm93Lg0KDQpCdXQgZnV0dXJlIGRldmVsb3BlcnMgd29u4oCZ
dCBiZSBhYmxlIHRvIHJlYWQgdGhlIHJlYXNvbiB3aHkgdGhlIGV4dGVuc2lvbiBwb2ludCBpcyBn
aXZlbiBvbmx5IGZvciBjb25maWRlbnRpYWwgY2xpZW50cy4NCg0KDQoNCk9uIE1heSAxNCwgMjAy
MCwgYXQgMTg6MzIsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0
PjxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQoNCg0KQXJlIHlvdSBh
d2FyZSBvZiBhbnkgc3VpdGFibGUgbWVjaGFuaXNtPyBJ4oCZbSBhc2tpbmcgc2luY2UgZnJvbSBt
eSBwZXJzcGVjdGl2ZSB0aGlzIGNsYXVzZSBpcyBtYWlubHkgaW50ZW5kZWQgdG8gYWxsb3cgZXhp
c3RpbmcgT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHMgdG8gdXNlIG5vbmNlIGluc3RlYWQgb2Yg
UEtDRSBpbiBjb21iaW5hdGlvbiB3aXRoIE9BdXRoIDIuMS4gSXTigJlzIGEgY29tcHJvbWlzZS4g
SSB0aGluayB3ZSBzaG91bGQgbm90IGVuY291cmFnZSBvdGhlcnMgdG8gaW52ZW50IHRoZWlyIG93
biBPQXV0aCBzZWN1cml0eSBtZWNoYW5pc21zLg0KDQoNCg0KT24gMTQuIE1heSAyMDIwLCBhdCAw
OTozNywgTm92IE1hdGFrZSA8bWF0YWtlQGdtYWlsLmNvbT48bWFpbHRvOm1hdGFrZUBnbWFpbC5j
b20+IHdyb3RlOg0KDQoNCg0KSGksDQoNCg0KDQpXaHkgbm90IGFsbG93aW5nIHB1YmxpYyBjbGll
bnRzIHVzZSAib3RoZXIgc3VpdGFibGUgbWVjaGFuaXNtc+KAnSB0aGVuPw0KDQpPQXV0aCBXRyBj
YW4gYWxsb3cgYm90aCB0eXBlIG9mIGNsaWVudHMgZG8gc28sIHRoZW4gT0lERiB3aWxsIGRlZmlu
ZSBub25jZSBhcyB0aGUgYWx0ZXJuYXRpdmUgb25seSBmb3IgY29uZmlkZW50aWFsIGNsaWVudHMu
DQoNCg0KDQoyMDIwLzA1LzE0IDE1OjU244CBVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00
MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz48bWFpbHRvOnRvcnN0ZW49NDBsb2RkZXJz
dGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+44Gu44Oh44O844OrOg0KDQoNCg0KSGkgYWxsLA0KDQoN
Cg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmsgZXZlcnlib2R5IGZvciB0aGUgc3Vic3RhbnRp
YWwgZGlzY3Vzc2lvbi4NCg0KDQoNClRoZSBwcm9wb3NlZCBjaGFuZ2UgZm9yIFNlY3Rpb24gNC4x
LjIuMSB3b3JrcyBmb3IgbWUgKGFzIGFscmVhZHkgc3RhdGVkKS4gSeKAmW0gbm90IGZ1bGx5IGNv
bWZvcnRhYmxlIHdpdGggdGhlIHByb3Bvc2VkIGNoYW5nZSBmb3IgU2VjdGlvbiA5LjcgZm9yIHRo
ZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KDQoNCi0gVGhlIHRleHQgaXMgd2Vha2VyIHRoYW4gU2Vj
dGlvbiA0LjEuMi4xIHNpbmNlIGl0IFJFQ09NTUVORFMgdXNlIG9mIFBLQ0UgaW5zdGVhZCBvZiBy
ZXF1aXJpbmcgaXQgKHdpdGggYSB3ZWxsLWRlZmluZWQgZXhjZXB0aW9uKS4NCg0KLSBHaXZlbiB0
aGUgbGF0ZXN0IGZpbmRpbmdzIHJlIG5vbmNlIEkgZG9u4oCZdCBmZWVsIGNvbWZvcnRhYmxlIHdp
dGggcmVjb21tZW5kaW5nIGFueSBtZWNoYW5pc20gdGhhdCB0aGlzIFdHIGlzIG5vdCByZXNwb25z
aWJsZSBmb3IgYW5kIHRodXMgZGlkIG5vdCBjb25kdWN0IHRoZSBzZWN1cml0eSB0aHJlYXQgYW5h
bHlzaXMgZm9yLiBJIHRoaW5rIHRoZSBiZXR0ZXIgd2F5IGZvciB1cyBhcyBXRyBpcyB0byBkZWZp
bmUgdGhlIGV4dGVuc2lvbiBwb2ludCBmb3Igb3RoZXIgbWVjaGFuaXNtcy4gVGhlIE9wZW5JRCBG
b3VuZGF0aW9uIChvciBhbnkgb3RoZXIgYm9keSkgY2FuIHRoZW4gZmlsbCBpbiBhbmQgaXNzdWUg
YSBzdGF0ZW1lbnQgdGhhdCBub25jZSAob3IgYW5vdGhlciBzdWl0YWJsZSBtZWNoYW5pc20pIGZ1
bGZpbHMgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGUgZXh0ZW5zaW9uIHBvaW50Lg0KDQoNCg0KQmFz
ZWQgb24gdGhpcyBjb25zaWRlcmF0aW9ucywgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dCBm
b3IgU2VjdGlvbiA5Ljc6DQoNCg0KDQpDbGllbnRzIE1VU1QgcHJldmVudCBpbmplY3Rpb24gKHJl
cGxheSkgb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBpbnRvDQoNCnRoZSBhdXRob3JpemF0aW9uIHJl
c3BvbnNlIGJ5IGF0dGFja2Vycy4gUHVibGljIGNsaWVudHMgTVVTVCB1c2UgdGhlDQoNCiJjb2Rl
X2NoYWxsZW5nZeKAnSB3aXRoIGEgdHJhbnNhY3Rpb24tc3BlY2lmaWMgdmFsdWUgdGhhdCBpcyBz
ZWN1cmVseQ0KDQpib3VuZCB0byB0aGUgY2xpZW50IGFuZCB0aGUgdXNlciBhZ2VudCBpbiB3aGlj
aCB0aGUgdHJhbnNhY3Rpb24gd2FzDQoNCnN0YXJ0ZWQuIENvbmZpZGVudGlhbCBjbGllbnRzIE1V
U1QgdXNlIHRoZSDigJxjb2RlX2NoYWxsZW5nZeKAnSBpbiB0aGUNCg0Kc2FtZSB3YXkgb3Igb3Ro
ZXIgc3VpdGFibGUgbWVjaGFuaXNtcyB0byBtaXRpZ2F0ZSBhdXRob3JpemF0aW9uIGNvZGUNCg0K
aW5qZWN0aW9uLg0KDQoNCg0KVGhpcyB0ZXh0IGZvbGxvd3MgdGhlIGxvZ2ljIGluIFNlY3Rpb24g
NC4xLjIuMSBhbmQgYWxsb3dzIHVzZSBvZiB0aGUgbm9uY2UgZm9yIGNvbmZpZGVudGlhbCBjbGll
bnRzLg0KDQoNCg0KYmVzdCByZWdhcmRzLA0KDQpUb3JzdGVuLg0KDQoNCg0KT24gMTIuIE1heSAy
MDIwLCBhdCAwMjoyMSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21A
ZG1hcmMuaWV0Zi5vcmc+PG1haWx0bzpNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZz4gd3JvdGU6DQoNCg0KDQpUaGF0IHdvcmtzIGZvciBtZS4gIFRoYW5rcyBhbGwg
Zm9yIHRoZSB1c2VmdWwgYmFjay1hbmQtZm9ydGggdGhhdCBnb3QgdXMgdG8gdGhpcyBwb2ludCBv
ZiBjbGFyaXR5LiAgSSBzdXNwZWN0IG1hbnkgb2YgdXMgbGVhcm5lZCB0aGluZ3MgYWxvbmcgdGhl
IHdheTsgSSBrbm93IHRoYXQgSSBkaWQhDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KRnJvbTogQWFy
b24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb20+PG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4N
Cg0KU2VudDogTW9uZGF5LCBNYXkgMTEsIDIwMjAgNDo1NSBQTQ0KDQpUbzogT0F1dGggV0cgPG9h
dXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQoNCkNjOiBOZWlsIE1hZGRlbiA8
bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT48bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5j
b20+OyBNaWtlIEpvbmVzDQoNCjxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHBy
b3Bvc2VkIHJlc29sdXRpb24gZm9yIFBLQ0UgaW4gT0F1dGggMi4xDQoNCg0KDQpUaGFuayB5b3Ug
TmVpbC4NCg0KDQoNClRvIGFkZHJlc3MgTWlrZSdzIGNvbmNlcm5zIGluIHRoZSBwcmV2aW91cyB0
aHJlYWRzLCBJIHdvdWxkIGxpa2UgdG8gYWxzbyB1cGRhdGUgc2VjdGlvbiA5Ljcgd2l0aCB0aGUg
Zm9sbG93aW5nIHRleHQ6DQoNCg0KDQpDbGllbnRzIE1VU1QgcHJldmVudCBpbmplY3Rpb24gKHJl
cGxheSkgb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBpbnRvDQoNCnRoZSBhdXRob3JpemF0aW9uIHJl
c3BvbnNlIGJ5IGF0dGFja2Vycy4gVGhlIHVzZSBvZiB0aGUNCg0KYGNvZGVfY2hhbGxlbmdlYCBw
YXJhbWV0ZXIgaXMgUkVDT01NRU5ERUQgdG8gdGhpcyBlbmQuIEZvcg0KDQpjb25maWRlbnRpYWwg
Y2xpZW50cywgdGhlIE9wZW5JRCBDb25uZWN0IGBub25jZWAgcGFyYW1ldGVyIGFuZCBJRA0KDQpU
b2tlbiBDbGFpbSB7e09wZW5JRH19IE1BWSBiZSB1c2VkIGluc3RlYWQgb2Ygb3IgaW4gYWRkaXRp
b24gdG8gdGhlDQoNCmBjb2RlX2NoYWxsZW5nZWAgcGFyYW1ldGVyIGZvciB0aGlzIHB1cnBvc2Uu
IFRoZSBgY29kZV9jaGFsbGVuZ2VgDQoNCm9yIE9wZW5JRCBDb25uZWN0IGBub25jZWAgdmFsdWUg
TVVTVCBiZSB0cmFuc2FjdGlvbi1zcGVjaWZpYyBhbmQNCg0Kc2VjdXJlbHkgYm91bmQgdG8gdGhl
IGNsaWVudCBhbmQgdGhlIHVzZXIgYWdlbnQgaW4gd2hpY2ggdGhlIHRyYW5zYWN0aW9uIHdhcyBz
dGFydGVkLg0KDQoNCg0KVGhpcyBjaGFuZ2UgYmV0dGVyIGNsYXJpZmllcyB0aGUgc3BlY2lmaWMg
Y2lyY3Vtc3RhbmNlcyB1bmRlciB3aGljaCB0aGUgIm5vbmNlIiBwYXJhbWV0ZXIgaXMgc3VmZmlj
aWVudCB0byBwcm90ZWN0IGFnYWluc3QgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbi4NCg0K
DQoNCkFhcm9uIFBhcmVja2kNCg0KDQoNCk9uIE1vbiwgTWF5IDExLCAyMDIwIGF0IDExOjU1IEFN
IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPjxtYWlsdG86bmVpbC5tYWRk
ZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQoNCkkgYW0gaGFwcHkgd2l0aCB0aGlzIHByb3Bvc2Vk
IHdvcmRpbmcuIFRoYW5rcyBmb3IgdXBkYXRpbmcgaXQuDQoNCg0KDQrigJQgTmVpbA0KDQoNCg0K
DQoNCk9uIDExIE1heSAyMDIwLCBhdCAxOTo1MiwgQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNr
aS5jb20+PG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4gd3JvdGU6DQoNCg0KDQpUaGFua3MgZm9y
IHRoZSBsaXZlbHkgZGlzY3Vzc2lvbiBhcm91bmQgUEtDRSBpbiBPQXV0aCAyLjEgZXZlcnlvbmUh
DQoNCg0KDQpXZSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0LCB3aGlj
aCBpcyBhIHNsaWdodCB2YXJpYXRpb24gZnJvbSB0aGUgdGV4dCBOZWlsIHByb3Bvc2VkLiBUaGlz
IHdvdWxkIHJlcGxhY2UgdGhlIHBhcmFncmFwaCBpbiA0LjEuMi4xIChodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtcGFyZWNraS1vYXV0aC12Mi0xLTAyI3NlY3Rpb24tNC4xLjIuMSkg
dGhhdCBiZWdpbnMgd2l0aCAiSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBzZW5kIHRoZSAiY29kZV9j
aGFsbGVuZ2UiIGluIHRoZSByZXF1ZXN0Li4uIg0KDQoNCg0KIkFuIEFTIE1VU1QgcmVqZWN0IHJl
cXVlc3RzIHdpdGhvdXQgYSBjb2RlX2NoYWxsZW5nZSBmcm9tIHB1YmxpYyBjbGllbnRzLCBhbmQg
TVVTVCByZWplY3Qgc3VjaCByZXF1ZXN0cyBmcm9tIG90aGVyIGNsaWVudHMgdW5sZXNzIHRoZXJl
IGlzIHJlYXNvbmFibGUgYXNzdXJhbmNlIHRoYXQgdGhlIGNsaWVudCBtaXRpZ2F0ZXMgYXV0aG9y
aXphdGlvbiBjb2RlIGluamVjdGlvbiBpbiBvdGhlciB3YXlzLi4gU2VlIHNlY3Rpb24gOS43IGZv
ciBkZXRhaWxzLiINCg0KDQoNClNlY3Rpb24gOS43IGlzIHdoZXJlIHRoZSBudWFuY2VzIG9mIFBL
Q0UgdnMgbm9uY2UgYXJlIGRlc2NyaWJlZC4NCg0KDQoNCkFzIE5laWwgZGVzY3JpYmVkLCB3ZSBi
ZWxpZXZlIHRoaXMgd2lsbCBhbGxvdyBBU3MgdG8gc3VwcG9ydCBib3RoIE9BdXRoIDIuMCBhbmQg
Mi4xIGNsaWVudHMgc2ltdWx0YW5lb3VzbHkuIFRoZSBjaGFuZ2UgZnJvbSBOZWlsJ3MgdGV4dCBp
cyB0aGUgY2xhcmlmaWNhdGlvbiBvZiB3aGljaCB0aHJlYXRzLCBhbmQgY2hhbmdpbmcgdG8gTVVT
VCBpbnN0ZWFkIG9mIFNIT1VMRC4gVGhlICJNVVNULi4udW5sZXNzIiBpcyBtb3JlIHNwZWNpZmlj
IHRoYW4gIlNIT1VMRCIsIGFuZCBzaW5jZSB3ZSBhcmUgYWxyZWFkeSBkZXNjcmliaW5nIHRoZSBl
eHBsaWNpdCBleGNlcHRpb24gdG8gdGhlIHJ1bGUsIGl0J3MgbW9yZSBjbGVhciBhcyBhIE1VU1Qg
aGVyZS4NCg0KDQoNCkFhcm9uIFBhcmVja2kNCg0KDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlz
dA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpP
QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg==

--_000_MN2PR00MB0688FA432C1351809AAABF24F5B90MN2PR00MB0688namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg
c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46
MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p
bHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAw
MjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K
CXttc28tbGlzdC1pZDoxMDQ4MzM0NTUxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0Njk3OTAw
MzQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5TbyBpdCBzb3VuZHMgbWUgbGlrZSB0aGUgZml4IGlz
IHRvIGhhdmUgc2VydmVycyByZWplY3QgUEtDRSByZXF1ZXN0cyB3aXRoIGluY29tcGxldGUgcGFy
YW1ldGVyIHNldHM6IHJlcXVlc3RzIHRoYXQgb25seSBjb250YWlucyBvbmUgb2YgY29kZV9jaGFs
bGVuZ2UgYW5kIGNvZGVfdmVyaWZpZWQuJm5ic3A7IFdpbGwgdGhhdCBlbGltaW5hdGUgdGhlIGF0
dGFjaywgTm92PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91
bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCk5vdiBNYXRha2U8YnI+DQo8
Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMTgsIDIwMjAgMTE6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+
IERhbmllbCBGZXR0ICZsdDtmZXR0QGRhbmllbGZldHQuZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBv
YXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBwcm9wb3Nl
ZCByZXNvbHV0aW9uIGZvciBQS0NFIGluIE9BdXRoIDIuMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUsIGZlZWwgZnJlZSB0byBhZGQgdGhlIHNlbmFy
aW8gdG8geW91ciBwb3N0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkZZSTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm15IE9BdXRo
MiBzZXJ2ZXIgcnVieSBnZW0gcmVqZWN0cyBzdWNoIHRva2VuIHJlcXVlc3RzLDxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi
LmNvbS9ub3YvcmFjay1vYXV0aDIvYmxvYi9tYXN0ZXIvbGliL3JhY2svb2F1dGgyL3NlcnZlci9l
eHRlbnNpb24vcGtjZS5yYiNMMjgiPmh0dHBzOi8vZ2l0aHViLmNvbS9ub3YvcmFjay1vYXV0aDIv
YmxvYi9tYXN0ZXIvbGliL3JhY2svb2F1dGgyL3NlcnZlci9leHRlbnNpb24vcGtjZS5yYiNMMjg8
L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h
bmQgR29vZ2xlIGFsc28gZG9lcyB0aGUgc2FtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2lzdC5naXRodWIuY29t
L25vdi85ZmViYTg2Njg1YmQzYjE4YjRiZjdiZmI4ODAyMjA0NiI+aHR0cHM6Ly9naXN0LmdpdGh1
Yi5jb20vbm92LzlmZWJhODY2ODViZDNiMThiNGJmN2JmYjg4MDIyMDQ2PC9hPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBJJ20gZ3Vlc3Np
bmcgc3VjaCBiZWhhdmlvciBpcyByZWxhdGl2ZWx5IHJhcmUtY2FzZSwgaG9wZWZ1bGx5LjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pUGFkPHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44GL44KJ6YCB5L+hPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+MjAyMC8wNS8xOSAxNTo0MzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtNUyBHb3RoaWMmcXVvdDsiPuOAgTwvc3Bhbj5EYW5pZWwgRmV0dCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmZldHRAZGFuaWVsZmV0dC5kZSI+ZmV0dEBkYW5pZWxmZXR0LmRlPC9hPiZndDs8c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jga7jg6Hjg7zjg6s8L3Nw
YW4+OjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj7vu78gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkFtIDE5LjA1LjIwIHVtIDA0OjU1IHNjaHJpZWIgTm92IE1hdGFrZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRob3VnaHQgdGhlIHNlcnZlciBNVVNU
IHJlamVjdCBzdWNoIHRva2VuIHJlcXVlc3RzLCBidXQgSSBjb3VsZG7igJl0IGZpbmQgc3VjaCBk
ZWZpbml0aW9uIGluIFJGQzc2MzYuLi4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7VGhlIGNsaWVudCB3aWxsIHNl
bmQgdGhlIGNvZGUsIGFsb25nIHdpdGggYSAobm93IG5vdCBtYXRjaGluZykgY29kZV92ZXJpZmll
ciB0byB0aGUgc2VydmVyLiBUaGUgc2VydmVyIHdpbGwgaWdub3JlIHRoZSBjb2RlX3ZlcmlmaWVy
IChhcyBpdCB3YXMgbm90IGV4cGVjdGVkKSBhbmQgc2VuZCBiYWNrIGFuIGFjY2VzcyB0b2tlbiBh
bmQgSUQgdG9rZW4gdG8gdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGFuaWVsZmV0dC5kZS8yMDIw
LzA1LzE2L3BrY2UtdnMtbm9uY2UtZXF1aXZhbGVudC1vci1ub3QvI25vbmNlcGtjZS1zaWRlc3Rl
cC1hdHRhY2siPmh0dHBzOi8vZGFuaWVsZmV0dC5kZS8yMDIwLzA1LzE2L3BrY2UtdnMtbm9uY2Ut
ZXF1aXZhbGVudC1vci1ub3QvI25vbmNlcGtjZS1zaWRlc3RlcC1hdHRhY2s8L2E+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0
aGUgYmVoYXZpb3IgaXMgYWNjZXB0YWJsZSBieSBSRkM3NjM2LCAmcXVvdDtOb25jZS9QS0NFIFNp
ZGVzdGVwIEF0dGFja+KAnSB3b3VsZCBiZSBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+SSAqdGhpbmsqIHRo
YXQgdGhlcmUgaXMgbm90aGluZyBwcmV2ZW50aW5nIHNlcnZlcnMgZnJvbSBzb21ldGltZXMgdXNp
bmcgUEtDRSBhbmQgc29tZXRpbWVzIHVzaW5nIE5vbmNlLiBJIGFzc3VtZSB0aGF0IHRoaXMgaXMg
b3V0IG9mIHRoZSBzY29wZSBvZiB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMuDQo8bzpwPjwv
bzpwPjwvcD4NCjxwPkkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBoZWFyIGhvdyBhY3R1YWwgaW1w
bGVtZW50YXRpb25zIGhhbmRsZSB0aGlzIGluIHByYWN0aWNlLjxvOnA+PC9vOnA+PC9wPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsdXMsIHdpdGggc3Vj
aCBBUyBiZWhhdmlvciwgQ1NSRiBwcm90ZWN0aW9uIHVzaW5nIFBLQ0UgY2FuIGFsc28gYmUgYnlw
YXNzZWQgYXMgYmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4xLiBUaGUgYXR0YWNrZXIgcmVtb3ZlcyBjb2RlX2NoYWxsZW5nZSBmcm9tIGhp
cy9oZXIgb3duIEF1dGhaIFJlcSwmbmJzcDtyZWNlaXZlcyZuYnNwO2Egbm9uLWNvZGVfY2hhbGxl
bmdlLWJvdW5kIGNvZGUsIGFuZCBzZW5kcyBpdCB0byB0aGUgdmljdGltLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVGhlIGNsaWVudCByZWNl
aXZlcyB0aGUgYXR0YWNrZXLigJlzIGNvZGUgZnJvbSB0aGUgdmljdGltLCBhbmQgc2VuZHMgaXQg
dG8gdGhlIEFTIHcvIHRoZSB2YWxpZCBjb2RlX3ZlcmlmaWVyIGJvdW5kIHRvIHRoZSB2aWN0aW3i
gJlzIGJyb3dzZXIgc2Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjMuIFRoZSBBUyBpZ25vcmVzIHRoZSBjb2RlX3ZlcmlmaWVyIGFuZCBy
ZXR1cm5zIHRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SWYgdGhhdOKAmXMgdGhlIGNhc2UsIGN1cnJlbnQgT0F1dGggMi4wIFBLQ0Ug
aW1wbGVtZW50YXRpb24gY2FuIGJlIHdlYWtlciB0aGFuIGV4cGVjdGVkLi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPkV4Y2VsbGVudCBw
b2ludCE8bzpwPjwvbzpwPjwvcD4NCjxwPldvdWxkIGl0IGJlIG9rYXkgaWYgSSBhZGQgdGhhdCBh
dHRhY2sgdG8gdGhlIG9yaWdpbmFsIHBvc3QgKHdpdGggY3JlZGl0cywgb2YgY291cnNlKT88bzpw
PjwvbzpwPjwvcD4NCjxwPi1EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMjAvMDUvMTkgMTo1NDxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOAgTwvc3Bhbj5EYW5p
ZWwgRmV0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZldHRAZGFuaWVsZmV0dC5kZSI+ZmV0dEBkYW5p
ZWxmZXR0LmRlPC9hPiZndDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj
JnF1b3Q7Ij7jga7jg6Hjg7zjg6s8L3NwYW4+OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFsa2luZyB0byBUb3JzdGVuLCB3ZSByZWFs
aXplZCB0aGF0IHByb3ZpZGluZyBhIGdlbmVyaWMgZXh0ZW5zaW9uIHBvaW50IGhlcmUgaXMgcHJv
YmFibHkgbm90IGEgZ29vZCBpZGVhLiBJdCBpcyByZWFsbHkgaGFyZCB0byB0ZWxsIHdoYXQgcHJv
dGVjdHMgeW91IGZyb20gY29kZSBpbmplY3Rpb24gYW5kIHdoYXQgZG9lcyBub3QsIGFuZCBwZW9w
bGUgbWlnaHQgY29tZSB1cCB3aXRoIGFsbCBzb3J0cyBvZiBub24tc3RhbmRhcmQNCiBhbmQgcG90
ZW50aWFsbHkgaW5zZWN1cmUgc29sdXRpb25zLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbiBqdXN0IGZvciBQS0NFIHZzLiBOb25jZSwg
aXQgaXMgbm90IG9idmlvdXMgaWYgdGhleSBwcm92aWRlIHRoZSBzYW1lIGxldmVsIG9mIHByb3Rl
Y3Rpb24uIEluIGFuIGF0dGVtcHQgdG8gYW5zd2VyIHRoaXMgcXVlc3Rpb24sIEkgdHJpZWQgdG8g
Y29tZSB1cCB3aXRoIGEgbW9yZSBzeXN0ZW1hdGljIGFuYWx5c2lzIG9mICZxdW90O1BLQ0UgdnMg
Tm9uY2UmcXVvdDsuIEkgd3JvdGUgdXAgbXkgcmVzdWx0cyBoZXJlOg0KPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2Rh
bmllbGZldHQuZGUvMjAyMC8wNS8xNi9wa2NlLXZzLW5vbmNlLWVxdWl2YWxlbnQtb3Itbm90LyI+
aHR0cHM6Ly9kYW5pZWxmZXR0LmRlLzIwMjAvMDUvMTYvcGtjZS12cy1ub25jZS1lcXVpdmFsZW50
LW9yLW5vdC88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxicj4NCkFsdGhvdWdoIHRoaXMgaXMgbm90IGEgZm9ybWFsIGFuYWx5c2lzLCBJIGhvcGUgdGhh
dCBJIGhhdmUgY292ZXJlZCBhbGwgaW50ZXJlc3RpbmcgY2FzZXMuIFBsZWFzZSByZXZpZXcgdGhl
IHRleHQgYW5kIGxldCBtZSBrbm93IGlmIEkgaGF2ZSBtaXNzZWQgc29tZXRoaW5nIG9yIGlmIHRo
ZXJlIGFyZSBhbnkgbWlzdGFrZXMuPGJyPg0KPGJyPg0KVGhlIG1haW4gcmVzdWx0cyBhcmU6PG86
cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJbiB0ZXJtcyBvZiBwcm90ZWN0aW9uIGFn
YWluc3QgQ1NSRiBhbmQgY29kZSBtaXN1c2UsIFBLQ0UgYW5kIE5vbmNlIHByb3ZpZGUgc2ltaWxh
ciBsZXZlbHMgb2Ygc2VjdXJpdHksIHdpdGggYSBzbGlnaHQgYWR2YW50YWdlIGZvciBQS0NFLjxv
OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBs
Zm8xIj4NCkluIHByYWN0aWNlLCBhIGNpcmN1bXZlbnRpb24gb2YgYm90aCBtZWNoYW5pc21zLCBo
b3dldmVyLCBpcyBwb3NzaWJsZSBpZiBhbiBBUyBhbGxvd3MgYSBjbGllbnQgdG8gY2hvb3NlIGJl
dHdlZW4gUEtDRSBhbmQgTm9uY2UgYW5kIHRoZSBjbGllbnQgbWFrZXMgdXNlIG9mIHRoaXMgZnJl
ZWRvbS4gSSBwcm9wb3NlIHRvIGNhbGwgdGhpcyBhdHRhY2sgdGhlIE5vbmNlL1BLQ0UgU2lkZXN0
ZXAgQXR0YWNrLiDihpIgUGxlYXNlIHJldmlldyB0aGUgYXR0YWNrDQogZGVzY3JpcHRpb24gaW4g
dGhlIGFuYWx5c2lzLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s
aXN0OmwwIGxldmVsMSBsZm8xIj4NClRvIGF2b2lkIHRoZSBOb25jZS9QS0NFIFNpZGVzdGVwIEF0
dGFjaywgY2xpZW50cyBtdXN0IG5vdCBzd2l0Y2ggYmV0d2VlbiB1c2luZyBvbmx5IFBLQ0UgYW5k
IG9ubHkgTm9uY2UgKGJ1dCBtYXkgdXNlIGJvdGggaW4gcGFyYWxsZWwsIG9yIHN3aXRjaCBiZXR3
ZWVuIHVzaW5nIG9ubHkgUEtDRSBhbmQgUEtDRSYjNDM7Tm9uY2UpLiBBdXRob3JpemF0aW9uIHNl
cnZlcnMgbXVzdCBlbmZvcmNlIFBLQ0UgdW5sZXNzIHRoZXkga25vdyB0aGF0IHRoZSBjbGllbnQN
CiB1c2VzIE5vbmNlIGZvciBhbGwgb2YgaXRzIGZsb3dzIChhbmQgY2hlY2tzIHRoZSBOb25jZSB2
YWx1ZSkuIFRoZSBwcmVzZW5jZSBvZiBhIG5vbmNlIHBhcmFtZXRlciBpbiB0aGUgYXV0aG9yaXph
dGlvbiByZXF1ZXN0IGlzIG5vdCBzdWZmaWNpZW50IHRvIGRldGVybWluZSBpZiBhIGNsaWVudCBh
Y3R1YWxseSBjaGVja3MgdGhlIG5vbmNlIGNsYWltIGluIHRoZSBJRCB0b2tlbi48bzpwPjwvbzpw
PjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgeW91IGNhbiBzZWUsIGFscmVh
ZHkgaGF2aW5nIHR3byBtb3JlLW9yLWxlc3Mgd2VsbC11bmRlcnN0b29kIG1lY2hhbmlzbXMgaXMg
aGFyZCBlbm91Z2ggdG8gd3JhcCB5b3VyIGhlYWQgYXJvdW5kIGZyb20gYSBzZWN1cml0eSBzdGFu
ZHBvaW50LiBXZSBzaG91bGQgdGhlcmVmb3JlIG1ha2UgUEtDRSB0aGUNCiBkZWZhdWx0IGFuZCBO
b25jZSBhbiBvcHRpb24gZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyB0aGlzIGVuZCwgSSB3b3VsZCBsaWtlIHRvIHBy
b3Bvc2UgdGhlIGZvbGx3aW5nIHN0cmF3bWFuLCBiYXNlZCBvbiBUb3JzdGVuJ3MgYW5kIEFhcm9u
J3Mgc3VnZ2VzdGlvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dHQ+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFuIEFTIE1VU1QgcmVqZWN0IHJlcXVlc3Rz
IHdpdGhvdXQgYSBjb2RlX2NoYWxsZW5nZSBmcm9tIHB1YmxpYzwvc3Bhbj48L3R0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48YnI+DQo8dHQ+Y2xpZW50cywgYW5kIE1VU1QgcmVqZWN0IHN1Y2ggcmVxdWVzdHMgZnJvbSBv
dGhlciBjbGllbnRzIHVubGVzcyB0aGVyZTwvdHQ+PGJyPg0KPHR0PmlzIHJlYXNvbmFibGUgYXNz
dXJhbmNlIHRoYXQgdGhlIGNsaWVudCBtaXRpZ2F0ZXMgYXV0aG9yaXphdGlvbiBjb2RlPC90dD48
YnI+DQo8dHQ+aW5qZWN0aW9uIHVzaW5nIHRoZSBPcGVuSUQgQ29ubmVjdCBOb25jZSBtZWNoYW5p
c20gYW5kIHRoYXQgdGhpczwvdHQ+PGJyPg0KPHR0Pm1pdGlnYXRpb24gaXMgdXNlZCBmb3IgYWxs
IGludGVyYWN0aW9ucyB3aXRoIHRoZSBjbGllbnQuIFNlZSBzZWN0aW9uPC90dD48YnI+DQo8dHQ+
OS43IGZvciBkZXRhaWxzLjwvdHQ+PC9zcGFuPjxicj4NCjxicj4NClNlY3Rpb24gOS43Ojxicj4N
Cjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Q2xpZW50cyBNVVNUIHBy
ZXZlbnQgaW5qZWN0aW9uIChyZXBsYXkpIG9mIGF1dGhvcml6YXRpb24gY29kZXMgaW50bzwvc3Bh
bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+dGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgYnkg
YXR0YWNrZXJzLiBUaGUgdXNlIG9mIHRoZTwvdHQ+PGJyPg0KPHR0PmBjb2RlX2NoYWxsZW5nZWAg
cGFyYW1ldGVyIGlzIFJFQ09NTUVOREVEIHRvIHRoaXMgZW5kLiBGb3I8L3R0Pjxicj4NCjx0dD5j
b25maWRlbnRpYWwgY2xpZW50cywgdGhlIE9wZW5JRCBDb25uZWN0IGBub25jZWAgcGFyYW1ldGVy
IGFuZCBJRDwvdHQ+PGJyPg0KPHR0PlRva2VuIENsYWltIHt7T3BlbklEfX0gTUFZIGJlIHVzZWQg
aW5zdGVhZCBvZiBvciBpbiBhZGRpdGlvbiB0byB0aGU8L3R0Pjxicj4NCjx0dD5gY29kZV9jaGFs
bGVuZ2VgIHBhcmFtZXRlciBmb3IgdGhpcyBwdXJwb3NlLiBUaGUgYGNvZGVfY2hhbGxlbmdlYCBv
cjwvdHQ+PGJyPg0KPHR0Pk9wZW5JRCBDb25uZWN0IGBub25jZWAgdmFsdWUgTVVTVCBiZSB0cmFu
c2FjdGlvbi1zcGVjaWZpYyBhbmQgc2VjdXJlbHk8L3R0Pjxicj4NCjx0dD5ib3VuZCB0byB0aGUg
Y2xpZW50IGFuZCB0aGUgdXNlciBhZ2VudCBpbiB3aGljaCB0aGUgdHJhbnNhY3Rpb24gd2FzPC90
dD48YnI+DQo8dHQ+c3RhcnRlZC48L3R0Pjxicj4NCjxicj4NCjx0dD5JZiB0aGUgT3BlbklEIENv
bm5lY3QgYG5vbmNlYCBpcyB1c2VkIHRvIG1pdGlnYXRlIGF1dGhvcml6YXRpb24gY29kZTwvdHQ+
PGJyPg0KPHR0PmluamVjdGlvbiBpbnN0ZWFkIG9mIGBjb2RlX2NoYWxsZW5nZWAsIGNsaWVudCBh
bmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8L3R0Pjxicj4NCjx0dD5NVVNUIGVuc3VyZSB0aGF0IHRo
ZSBtaXRpZ2F0aW9uIGlzIGFwcGxpZWQgdG8gZXZlcnkgaW50ZXJhY3Rpb24gd2l0aDwvdHQ+PGJy
Pg0KPHR0PnRoZSBjbGllbnQgYW5kIHRoYXQgdGhlIGNsaWVudCBjYW5ub3Qgc3dpdGNoIGJldHdl
ZW4gYGNvZGVfY2hhbGxlbmdlYDwvdHQ+PGJyPg0KPHR0PmFuZCBgbm9uY2VgLiBGb3IgZXhhbXBs
ZSwgdGhlIHByZXNlbmNlIG9mIGEgYG5vbmNlYCBwYXJhbWV0ZXIgaW4gdGhlPC90dD48YnI+DQo8
dHQ+YXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIG5vdCBzdWZmaWNpZW50IHRvIGRldGVybWluZSB0
aGF0IHRoZTwvdHQ+PGJyPg0KPHR0PmBjb2RlX3ZlcmlmaWVyYCBjaGVjayBjYW4gYmUgc2tpcHBl
ZC48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9mIGNvdXJzZSwgd2Ug
bmVlZCB0byBhZGFwdCB0aGUgd29yZGluZyBpbiB0aGUgU2VjdXJpdHkgQkNQIGFjY29yZGluZ2x5
LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tRGFuaWVsPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gMTUuMDUuMjAgdW0gMDE6MDEgc2NocmllYiBN
aWtlIEpvbmVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SSBhZ3JlZSB3aXRoIE5v
diB0aGF0IG9ic2N1cmluZyB0aGUgbGFuZ3VhZ2UgaW4gOS43IHdvdWxkIGJlIGEgZGlzc2Vydmlj
ZSB0byBkZXZlbG9wZXJzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPlRoZSBTZWN1cml0eSBCQ1AsIHdoaWNoIGhhcyBhbHJlYWR5IGdvaW5nIHRo
ZSBXR0xDLCBleHBsaWNpdGx5IGNhbGxzIG91dCB0aGUgdXNlIG9mIG5vbmNlIGFzIHBhcnQgb2Yg
dGhlIGJlc3QgcHJhY3RpY2VzLiZuYnNwOyBPQXV0aCAyLjEgc2hvdWxkIGRvIG5vIGxlc3MuPG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIDku
NyBsYW5ndWFnZSB0aGF0IEFhcm9uIHByb3Bvc2VkIHdhcyB0aGUgcmVzdWx0IG9mIG1hbnkgcGVv
cGxlJ3MgY29udHJpYnV0aW9ucyBhbmQgYSB2aWdvcm91cyBkaXNjdXNzaW9uLiZuYnNwOyBMZXQn
cyBwdWJsaXNoIHRoZSBuZXh0IHZlcnNpb24gb2YgMi4xIHdpdGggdGhhdCBsYW5ndWFnZSBpbnRh
Y3QsIGFzIEkgYmVsaWV2ZSBpdCByZXByZXNlbnRzIGF0IGxlYXN0IGEgbG9jYWwgcG9pbnQgb2Yg
aGFyZC13b24gY29uc2Vuc3VzLiZuYnNwOyBMZXQncyBnZXQgdGhhdCBsYW5ndWFnZSBpbnRvIHRo
ZSByZWNvcmQgb2YgZHJhZnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPlRoZXJlJ3MgYWx3YXlzIHRpbWUgdG8gZGViYXRlIGl0IGFuZCBjaGFu
Z2UgaXQgbGF0ZXIgaW4gc3Vic2VxdWVudCBkcmFmdHMsIGJ1dCBsZXQncyBub3Qgbm93IGxvc2Ug
d2hhdCBpdCB0b29rIGEgbG90IG9mIGVmZm9ydCB0byBhY2hpZXZlLjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiAgICBUaGFua3MsPG86cD48L286
cD48L3ByZT4NCjxwcmU+ICAgIC0tIE1pa2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkZyb206IE5vdiBNYXRha2UgPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBn
bWFpbC5jb20iPiZsdDttYXRha2VAZ21haWwuY29tJmd0OzwvYT4gPG86cD48L286cD48L3ByZT4N
CjxwcmU+U2VudDogVGh1cnNkYXksIE1heSAxNCwgMjAyMCAzOjE4IEFNPG86cD48L286cD48L3By
ZT4NCjxwcmU+VG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0Ij4mbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7PC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiBPQXV0aCBXRyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0
Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+OyBNaWtlIEpvbmVzIDxhIGhyZWY9Im1h
aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jv
c29mdC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBbT0FV
VEgtV0ddIHByb3Bvc2VkIHJlc29sdXRpb24gZm9yIFBLQ0UgaW4gT0F1dGggMi4xPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlcmUgaXMgbm8g
c3BlY2lmaWMgbWVjaGFuaXNtIHJpZ2h0IG5vdy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CdXQg
ZnV0dXJlIGRldmVsb3BlcnMgd29u4oCZdCBiZSBhYmxlIHRvIHJlYWQgdGhlIHJlYXNvbiB3aHkg
dGhlIGV4dGVuc2lvbiBwb2ludCBpcyBnaXZlbiBvbmx5IGZvciBjb25maWRlbnRpYWwgY2xpZW50
cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
Pk9uIE1heSAxNCwgMjAyMCwgYXQgMTg6MzIsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPGEgaHJlZj0i
bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij4mbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5u
ZXQmZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5BcmUgeW91IGF3YXJlIG9mIGFueSBzdWl0YWJsZSBtZWNoYW5pc20/IEni
gJltIGFza2luZyBzaW5jZSBmcm9tIG15IHBlcnNwZWN0aXZlIHRoaXMgY2xhdXNlIGlzIG1haW5s
eSBpbnRlbmRlZCB0byBhbGxvdyBleGlzdGluZyBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cyB0
byB1c2Ugbm9uY2UgaW5zdGVhZCBvZiBQS0NFIGluIGNvbWJpbmF0aW9uIHdpdGggT0F1dGggMi4x
LiBJdOKAmXMgYSBjb21wcm9taXNlLiBJIHRoaW5rIHdlIHNob3VsZCBub3QgZW5jb3VyYWdlIG90
aGVycyB0byBpbnZlbnQgdGhlaXIgb3duIE9BdXRoIHNlY3VyaXR5IG1lY2hhbmlzbXMuIDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+T24gMTQu
IE1heSAyMDIwLCBhdCAwOTozNywgTm92IE1hdGFrZSA8YSBocmVmPSJtYWlsdG86bWF0YWtlQGdt
YWlsLmNvbSI+Jmx0O21hdGFrZUBnbWFpbC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5IaSw8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5XaHkgbm90IGFsbG93aW5n
IHB1YmxpYyBjbGllbnRzIHVzZSAmcXVvdDtvdGhlciBzdWl0YWJsZSBtZWNoYW5pc21z4oCdIHRo
ZW4/PG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggV0cgY2FuIGFsbG93IGJvdGggdHlwZSBv
ZiBjbGllbnRzIGRvIHNvLCB0aGVuIE9JREYgd2lsbCBkZWZpbmUgbm9uY2UgYXMgdGhlIGFsdGVy
bmF0aXZlIG9ubHkgZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+MjAyMC8wNS8xNCAxNTo1NjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOAgTwvc3Bhbj5Ub3Jz
dGVuIExvZGRlcnN0ZWR0IDxhIGhyZWY9Im1haWx0bzp0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0
QGRtYXJjLmlldGYub3JnIj4mbHQ7dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRm
Lm9yZyZndDs8L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90
OyI+44Gu44Oh44O844OrPC9zcGFuPjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5IaSBhbGwsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSB3b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmsgZXZlcnli
b2R5IGZvciB0aGUgc3Vic3RhbnRpYWwgZGlzY3Vzc2lvbi4mbmJzcDsgPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIHByb3Bvc2VkIGNoYW5n
ZSBmb3IgU2VjdGlvbiA0LjEuMi4xIHdvcmtzIGZvciBtZSAoYXMgYWxyZWFkeSBzdGF0ZWQpLiBJ
4oCZbSBub3QgZnVsbHkgY29tZm9ydGFibGUgd2l0aCB0aGUgcHJvcG9zZWQgY2hhbmdlIGZvciBT
ZWN0aW9uIDkuNyBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0gVGhlIHRleHQgaXMgd2Vha2VyIHRo
YW4gU2VjdGlvbiA0LjEuMi4xIHNpbmNlIGl0IFJFQ09NTUVORFMgdXNlIG9mIFBLQ0UgaW5zdGVh
ZCBvZiByZXF1aXJpbmcgaXQgKHdpdGggYSB3ZWxsLWRlZmluZWQgZXhjZXB0aW9uKS48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4tIEdpdmVuIHRoZSBsYXRlc3QgZmluZGluZ3MgcmUgbm9uY2UgSSBk
b27igJl0IGZlZWwgY29tZm9ydGFibGUgd2l0aCByZWNvbW1lbmRpbmcgYW55IG1lY2hhbmlzbSB0
aGF0IHRoaXMgV0cgaXMgbm90IHJlc3BvbnNpYmxlIGZvciBhbmQgdGh1cyBkaWQgbm90IGNvbmR1
Y3QgdGhlIHNlY3VyaXR5IHRocmVhdCBhbmFseXNpcyBmb3IuIEkgdGhpbmsgdGhlIGJldHRlciB3
YXkgZm9yIHVzIGFzIFdHIGlzIHRvIGRlZmluZSB0aGUgZXh0ZW5zaW9uIHBvaW50IGZvciBvdGhl
ciBtZWNoYW5pc21zLiBUaGUgT3BlbklEIEZvdW5kYXRpb24gKG9yIGFueSBvdGhlciBib2R5KSBj
YW4gdGhlbiBmaWxsIGluIGFuZCBpc3N1ZSBhIHN0YXRlbWVudCB0aGF0IG5vbmNlIChvciBhbm90
aGVyIHN1aXRhYmxlIG1lY2hhbmlzbSkgZnVsZmlscyB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBl
eHRlbnNpb24gcG9pbnQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPkJhc2VkIG9uIHRoaXMgY29uc2lkZXJhdGlvbnMsIEkgcHJvcG9zZSB0aGUg
Zm9sbG93aW5nIHRleHQgZm9yIFNlY3Rpb24gOS43OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNsaWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlv
biAocmVwbGF5KSBvZiBhdXRob3JpemF0aW9uIGNvZGVzIGludG8gPG86cD48L286cD48L3ByZT4N
CjxwcmU+dGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgYnkgYXR0YWNrZXJzLiBQdWJsaWMgY2xp
ZW50cyBNVVNUIHVzZSB0aGUgPG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7Y29kZV9jaGFs
bGVuZ2XigJ0gd2l0aCBhIHRyYW5zYWN0aW9uLXNwZWNpZmljIHZhbHVlIHRoYXQgaXMgc2VjdXJl
bHkgPG86cD48L286cD48L3ByZT4NCjxwcmU+Ym91bmQgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVz
ZXIgYWdlbnQgaW4gd2hpY2ggdGhlIHRyYW5zYWN0aW9uIHdhcyA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5zdGFydGVkLiBDb25maWRlbnRpYWwgY2xpZW50cyBNVVNUIHVzZSB0aGUg4oCcY29kZV9j
aGFsbGVuZ2XigJ0gaW4gdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNhbWUgd2F5IG9yIG90
aGVyIHN1aXRhYmxlIG1lY2hhbmlzbXMgdG8gbWl0aWdhdGUgYXV0aG9yaXphdGlvbiBjb2RlIDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluamVjdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIHRleHQgZm9sbG93cyB0aGUgbG9naWMg
aW4gU2VjdGlvbiA0LjEuMi4xIGFuZCBhbGxvd3MgdXNlIG9mIHRoZSBub25jZSBmb3IgY29uZmlk
ZW50aWFsIGNsaWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+YmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvcnN0ZW4u
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
T24gMTIuIE1heSAyMDIwLCBhdCAwMjoyMSwgTWlrZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWlj
aGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPiZsdDtNaWNoYWVsLkpv
bmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8L2E+IHdyb3RlOjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYXQgd29ya3Mg
Zm9yIG1lLiZuYnNwOyBUaGFua3MgYWxsIGZvciB0aGUgdXNlZnVsIGJhY2stYW5kLWZvcnRoIHRo
YXQgZ290IHVzIHRvIHRoaXMgcG9pbnQgb2YgY2xhcml0eS4mbmJzcDsgSSBzdXNwZWN0IG1hbnkg
b2YgdXMgbGVhcm5lZCB0aGluZ3MgYWxvbmcgdGhlIHdheTsgSSBrbm93IHRoYXQgSSBkaWQhPG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IENoZWVycyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPkZyb206IEFhcm9uIFBhcmVja2kgPGEgaHJlZj0ibWFpbHRvOmFhcm9u
QHBhcmVja2kuY29tIj4mbHQ7YWFyb25AcGFyZWNraS5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlNlbnQ6IE1vbmRheSwgTWF5IDExLCAyMDIwIDQ6NTUgUE08bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5UbzogT0F1dGggV0cgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4m
bHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiBOZWls
IE1hZGRlbiA8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSI+Jmx0O25l
aWwubWFkZGVuQGZvcmdlcm9jay5jb20mZ3Q7PC9hPjsgTWlrZSBKb25lcyA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj4m
bHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBwcm9wb3NlZCByZXNvbHV0aW9uIGZvciBQS0NF
IGluIE9BdXRoIDIuMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPlRoYW5rIHlvdSBOZWlsLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRvIGFkZHJlc3MgTWlrZSdzIGNvbmNlcm5zIGluIHRoZSBw
cmV2aW91cyB0aHJlYWRzLCBJIHdvdWxkIGxpa2UgdG8gYWxzbyB1cGRhdGUgc2VjdGlvbiA5Ljcg
d2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+Q2xpZW50cyBNVVNUIHByZXZlbnQgaW5qZWN0aW9uIChyZXBs
YXkpIG9mIGF1dGhvcml6YXRpb24gY29kZXMgaW50byA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50
aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBieSBhdHRhY2tlcnMuIFRoZSB1c2Ugb2YgdGhlIDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmBjb2RlX2NoYWxsZW5nZWAgcGFyYW1ldGVyIGlzIFJFQ09N
TUVOREVEIHRvIHRoaXMgZW5kLiBGb3IgPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29uZmlkZW50
aWFsIGNsaWVudHMsIHRoZSBPcGVuSUQgQ29ubmVjdCBgbm9uY2VgIHBhcmFtZXRlciBhbmQgSUQg
PG86cD48L286cD48L3ByZT4NCjxwcmU+VG9rZW4gQ2xhaW0ge3tPcGVuSUR9fSBNQVkgYmUgdXNl
ZCBpbnN0ZWFkIG9mIG9yIGluIGFkZGl0aW9uIHRvIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5gY29kZV9jaGFsbGVuZ2VgIHBhcmFtZXRlciBmb3IgdGhpcyBwdXJwb3NlLiBUaGUgYGNvZGVf
Y2hhbGxlbmdlYCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vciBPcGVuSUQgQ29ubmVjdCBgbm9u
Y2VgIHZhbHVlIE1VU1QgYmUgdHJhbnNhY3Rpb24tc3BlY2lmaWMgYW5kIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPnNlY3VyZWx5IGJvdW5kIHRvIHRoZSBjbGllbnQgYW5kIHRoZSB1c2VyIGFnZW50
IGluIHdoaWNoIHRoZSB0cmFuc2FjdGlvbiB3YXMgc3RhcnRlZC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGNoYW5nZSBiZXR0ZXIgY2xh
cmlmaWVzIHRoZSBzcGVjaWZpYyBjaXJjdW1zdGFuY2VzIHVuZGVyIHdoaWNoIHRoZSAmcXVvdDtu
b25jZSZxdW90OyBwYXJhbWV0ZXIgaXMgc3VmZmljaWVudCB0byBwcm90ZWN0IGFnYWluc3QgYXV0
aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BYXJvbiBQYXJlY2tpPG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T24gTW9uLCBNYXkgMTEsIDIwMjAgYXQg
MTE6NTUgQU0gTmVpbCBNYWRkZW4gPGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9j
ay5jb20iPiZsdDtuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tJmd0OzwvYT4gd3JvdGU6PG86cD48
L286cD48L3ByZT4NCjxwcmU+SSBhbSBoYXBweSB3aXRoIHRoaXMgcHJvcG9zZWQgd29yZGluZy4g
VGhhbmtzIGZvciB1cGRhdGluZyBpdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT7igJQgTmVpbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9u
IDExIE1heSAyMDIwLCBhdCAxOTo1MiwgQWFyb24gUGFyZWNraSA8YSBocmVmPSJtYWlsdG86YWFy
b25AcGFyZWNraS5jb20iPiZsdDthYXJvbkBwYXJlY2tpLmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rcyBm
b3IgdGhlIGxpdmVseSBkaXNjdXNzaW9uIGFyb3VuZCBQS0NFIGluIE9BdXRoIDIuMSBldmVyeW9u
ZSEgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
V2Ugd291bGQgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dCwgd2hpY2ggaXMgYSBz
bGlnaHQgdmFyaWF0aW9uIGZyb20gdGhlIHRleHQgTmVpbCBwcm9wb3NlZC4gVGhpcyB3b3VsZCBy
ZXBsYWNlIHRoZSBwYXJhZ3JhcGggaW4gNC4xLjIuMSAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LXBhcmVja2ktb2F1dGgtdjItMS0wMiNzZWN0aW9uLTQuMS4yLjEi
Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXJlY2tpLW9hdXRoLXYyLTEtMDIj
c2VjdGlvbi00LjEuMi4xPC9hPikgdGhhdCBiZWdpbnMgd2l0aCAmcXVvdDtJZiB0aGUgY2xpZW50
IGRvZXMgbm90IHNlbmQgdGhlICZxdW90O2NvZGVfY2hhbGxlbmdlJnF1b3Q7IGluIHRoZSByZXF1
ZXN0Li4uJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+JnF1b3Q7QW4gQVMgTVVTVCByZWplY3QgcmVxdWVzdHMgd2l0aG91dCBhIGNvZGVf
Y2hhbGxlbmdlIGZyb20gcHVibGljIGNsaWVudHMsIGFuZCBNVVNUIHJlamVjdCBzdWNoIHJlcXVl
c3RzIGZyb20gb3RoZXIgY2xpZW50cyB1bmxlc3MgdGhlcmUgaXMgcmVhc29uYWJsZSBhc3N1cmFu
Y2UgdGhhdCB0aGUgY2xpZW50IG1pdGlnYXRlcyBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9u
IGluIG90aGVyIHdheXMuLiBTZWUgc2VjdGlvbiA5LjcgZm9yIGRldGFpbHMuJnF1b3Q7PG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2VjdGlvbiA5
LjcgaXMgd2hlcmUgdGhlIG51YW5jZXMgb2YgUEtDRSB2cyBub25jZSBhcmUgZGVzY3JpYmVkLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFzIE5l
aWwgZGVzY3JpYmVkLCB3ZSBiZWxpZXZlIHRoaXMgd2lsbCBhbGxvdyBBU3MgdG8gc3VwcG9ydCBi
b3RoIE9BdXRoIDIuMCBhbmQgMi4xIGNsaWVudHMgc2ltdWx0YW5lb3VzbHkuIFRoZSBjaGFuZ2Ug
ZnJvbSBOZWlsJ3MgdGV4dCBpcyB0aGUgY2xhcmlmaWNhdGlvbiBvZiB3aGljaCB0aHJlYXRzLCBh
bmQgY2hhbmdpbmcgdG8gTVVTVCBpbnN0ZWFkIG9mIFNIT1VMRC4gVGhlICZxdW90O01VU1QuLi51
bmxlc3MmcXVvdDsgaXMgbW9yZSBzcGVjaWZpYyB0aGFuICZxdW90O1NIT1VMRCZxdW90OywgYW5k
IHNpbmNlIHdlIGFyZSBhbHJlYWR5IGRlc2NyaWJpbmcgdGhlIGV4cGxpY2l0IGV4Y2VwdGlvbiB0
byB0aGUgcnVsZSwgaXQncyBtb3JlIGNsZWFyIGFzIGEgTVVTVCBoZXJlLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFhcm9uIFBhcmVja2k8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlz
dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+
T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlz
dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+
T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8
L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1
b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlz
dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+
T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_MN2PR00MB0688FA432C1351809AAABF24F5B90MN2PR00MB0688namp_--


From nobody Tue May 19 09:29:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3B93A07D6 for ; Tue, 19 May 2020 09:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.118
X-Spam-Level: 
X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_BL=1.979, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbYach8rP0-a for ; Tue, 19 May 2020 09:29:13 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40FBB3A07B3 for ; Tue, 19 May 2020 09:29:13 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id f6so81342pgm.1 for ; Tue, 19 May 2020 09:29:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rowfVjYMMt4DwspLp1z0rAUp4/nT3n/O1vVeRE4YqCs=; b=PF4mtG17t5+XNEZJmwMK+yB69mgtI20PiYP1yQUfkOJYl0l7p4Wn0XJYZFTgQ1+6hF 92dL0aX9trqjg4g1odS8h6EakmR8eWHHyzUDpH52aEe76IYcoMDq5RBrKlzqu7ed6wuS XhgQa5mEQTUQTKtZ9PimggfC5dNZwuGtumm7dzFfV5cCvPGQXNJ5XBXq2UJkpZJC0wEU 2oBm6i6gYV2/YQhlir+qcbrpvJ8TDFbSBxTCeJG9byAEOu0VGhv4JjSOyqm6CVA2qr6b oSswVLUft9y66DUlYi5qlZTiUYvnzrnm9/BRQbS+TpEp2DcFEeF/A/NSHvAyfBrfsdia 4H5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rowfVjYMMt4DwspLp1z0rAUp4/nT3n/O1vVeRE4YqCs=; b=HyOOb88L4gf02wedoxmRQZ1fpIjZwZbVxekn1F9LZ6VHDRyfwP22O2H1uybeHi9ANz /Oh8PBEHroVrAnlkYW5Ts8tYxKMbdt0xxsl2XC6vVXCRVEyR7qBIuowXBMDzB5VF88Ae ss1DrV/LaSRM83l2gWsNoN4jAdPK7MhRBbVhyQONEumI+ckFqowJA/sO8Q4l+MuDWapB hJFmEygSyPtss+Dp+XAdUkq9QYOkUxOICEbTEDVFSRBH0OvduWc9+n526h1K3LtrA6h/ yfA8SyZAANJs4yuLDHQqEaG4EFJXKmuU5Cxs/sHq+qAO5NQCj1AsN90CUrV5ItxhfoSz ne0g==
X-Gm-Message-State: AOAM532F4AyES/cF4uH3CWod7ue6IRy5cK3dmfUz1r7Xwy9sH/WzBOxQ eEUGJRPB8jhrxFOATN/VVWHIYeN1fSs=
X-Google-Smtp-Source: ABdhPJydWMpRFT15puDnX66XCVoixiJhSor2rNhXnW8ycVhYltQcpHBFYmQl1tuRQO266smE/Hs6Hg==
X-Received: by 2002:a63:3587:: with SMTP id c129mr50152pga.190.1589905752486;  Tue, 19 May 2020 09:29:12 -0700 (PDT)
Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id m9sm21047pgd.1.2020.05.19.09.29.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2020 09:29:11 -0700 (PDT)
From: Nov Matake 
Message-Id: <67F643A9-47E5-4339-B6B0-E39C7B959EF7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_38D4029F-2775-4A23-A7FF-1CFBA72E2474"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 20 May 2020 01:29:08 +0900
In-Reply-To: 
Cc: Daniel Fett , "oauth@ietf.org" 
To: Mike Jones 
References: 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 16:29:17 -0000

--Apple-Mail=_38D4029F-2775-4A23-A7FF-1CFBA72E2474
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes.

The root problem isn=E2=80=99t the mix-use of PKCE and nonce, it=E2=80=99s=
 PKCE implementation bug.
Yeah, all PKCE implementation MUST reject such requests, regardless =
it=E2=80=99s OAuth 2.1 or 2.0.

(and it=E2=80=99s probably because of PKCE spec=E2=80=99s ambiguity..)

> 2020/05/20 1:13=E3=80=81Mike Jones =
=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
>=20
> So it sounds me like the fix is to have servers reject PKCE requests =
with incomplete parameter sets: requests that only contains one of =
code_challenge and code_verified.  Will that eliminate the attack, Nov?
> =20
>                                                        -- Mike
> =20
> From: OAuth > =
On Behalf Of Nov Matake
> Sent: Monday, May 18, 2020 11:50 PM
> To: Daniel Fett >
> Cc: oauth@ietf.org 
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
> =20
> Sure, feel free to add the senario to your post.
> =20
> FYI:
> my OAuth2 server ruby gem rejects such token requests,
> =
https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/exte=
nsion/pkce.rb#L28 =

> and Google also does the same.
> https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046 =

> =20
> So I'm guessing such behavior is relatively rare-case, hopefully.
> =20
> iPad=E3=81=8B=E3=82=89=E9=80=81=E4=BF=A1
>=20
>=20
> 2020/05/19 15:43=E3=80=81Daniel Fett >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
>=20
> =EF=BB=BF=20
> Hi,
> =20
> Am 19.05.20 um 04:55 schrieb Nov Matake:
> I thought the server MUST reject such token requests, but I couldn=E2=80=
=99t find such definition in RFC7636...
> =20
> > The client will send the code, along with a (now not matching) =
code_verifier to the server. The server will ignore the code_verifier =
(as it was not expected) and send back an access token and ID token to =
the client.
> =
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkc=
e-sidestep-attack =

> =20
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep =
Attack=E2=80=9D would be possible.
> I *think* that there is nothing preventing servers from sometimes =
using PKCE and sometimes using Nonce. I assume that this is out of the =
scope of the existing specifications.
>=20
> I would be interested to hear how actual implementations handle this =
in practice.
>=20
> =20
> Plus, with such AS behavior, CSRF protection using PKCE can also be =
bypassed as below.
> 1. The attacker removes code_challenge from his/her own AuthZ Req, =
receives a non-code_challenge-bound code, and sends it to the victim.
> 2. The client receives the attacker=E2=80=99s code from the victim, =
and sends it to the AS w/ the valid code_verifier bound to the =
victim=E2=80=99s browser session.
> 3. The AS ignores the code_verifier and returns tokens.
> =20
> If that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can =
be weaker than expected..
> Excellent point!
>=20
> Would it be okay if I add that attack to the original post (with =
credits, of course)?
>=20
> -Daniel
>=20
> =20
> nov
>=20
>=20
> 2020/05/19 1:54=E3=80=81Daniel Fett >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
> =20
> Hi all,
> =20
> Talking to Torsten, we realized that providing a generic extension =
point here is probably not a good idea. It is really hard to tell what =
protects you from code injection and what does not, and people might =
come up with all sorts of non-standard and potentially insecure =
solutions.=20
> =20
> Even just for PKCE vs. Nonce, it is not obvious if they provide the =
same level of protection. In an attempt to answer this question, I tried =
to come up with a more systematic analysis of "PKCE vs Nonce". I wrote =
up my results here:
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ =

>=20
> Although this is not a formal analysis, I hope that I have covered all =
interesting cases. Please review the text and let me know if I have =
missed something or if there are any mistakes.
>=20
> The main results are:
> In terms of protection against CSRF and code misuse, PKCE and Nonce =
provide similar levels of security, with a slight advantage for PKCE.
> In practice, a circumvention of both mechanisms, however, is possible =
if an AS allows a client to choose between PKCE and Nonce and the client =
makes use of this freedom. I propose to call this attack the Nonce/PKCE =
Sidestep Attack. =E2=86=92 Please review the attack description in the =
analysis.
> To avoid the Nonce/PKCE Sidestep Attack, clients must not switch =
between using only PKCE and only Nonce (but may use both in parallel, or =
switch between using only PKCE and PKCE+Nonce). Authorization servers =
must enforce PKCE unless they know that the client uses Nonce for all of =
its flows (and checks the Nonce value). The presence of a nonce =
parameter in the authorization request is not sufficient to determine if =
a client actually checks the nonce claim in the ID token.
> As you can see, already having two more-or-less well-understood =
mechanisms is hard enough to wrap your head around from a security =
standpoint. We should therefore make PKCE the default and Nonce an =
option for backwards compatibility.
> To this end, I would like to propose the follwing strawman, based on =
Torsten's and Aaron's suggestions:
> An AS MUST reject requests without a code_challenge from public
> clients, and MUST reject such requests from other clients unless there
> is reasonable assurance that the client mitigates authorization code
> injection using the OpenID Connect Nonce mechanism and that this
> mitigation is used for all interactions with the client. See section
> 9.7 for details.
>=20
> Section 9.7:
>=20
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. The use of the
> `code_challenge` parameter is RECOMMENDED to this end. For
> confidential clients, the OpenID Connect `nonce` parameter and ID
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
> `code_challenge` parameter for this purpose. The `code_challenge` or
> OpenID Connect `nonce` value MUST be transaction-specific and securely
> bound to the client and the user agent in which the transaction was
> started.
>=20
> If the OpenID Connect `nonce` is used to mitigate authorization code
> injection instead of `code_challenge`, client and authorization server
> MUST ensure that the mitigation is applied to every interaction with
> the client and that the client cannot switch between `code_challenge`
> and `nonce`. For example, the presence of a `nonce` parameter in the
> authorization request is not sufficient to determine that the
> `code_verifier` check can be skipped.
> =20
> Of course, we need to adapt the wording in the Security BCP =
accordingly.
> -Daniel
> =20
> =20
> Am 15.05.20 um 01:01 schrieb Mike Jones:
> I agree with Nov that obscuring the language in 9.7 would be a =
disservice to developers.
> =20
> The Security BCP, which has already going the WGLC, explicitly calls =
out the use of nonce as part of the best practices.  OAuth 2.1 should do =
no less.
> =20
> The 9.7 language that Aaron proposed was the result of many people's =
contributions and a vigorous discussion.  Let's publish the next version =
of 2.1 with that language intact, as I believe it represents at least a =
local point of hard-won consensus.  Let's get that language into the =
record of drafts.
> =20
> There's always time to debate it and change it later in subsequent =
drafts, but let's not now lose what it took a lot of effort to achieve.
> =20
>     Thanks,
>     -- Mike
> =20
> -----Original Message-----
> From: Nov Matake  =20
> Sent: Thursday, May 14, 2020 3:18 AM
> To: Torsten Lodderstedt  =

> Cc: OAuth WG  ; Mike Jones =
 
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
> =20
> There is no specific mechanism right now.
> But future developers won=E2=80=99t be able to read the reason why the =
extension point is given only for confidential clients.
> =20
> On May 14, 2020, at 18:32, Torsten Lodderstedt =
  wrote:
> =20
> Are you aware of any suitable mechanism? I=E2=80=99m asking since from =
my perspective this clause is mainly intended to allow existing OpenID =
Connect deployments to use nonce instead of PKCE in combination with =
OAuth 2.1. It=E2=80=99s a compromise. I think we should not encourage =
others to invent their own OAuth security mechanisms.=20
> =20
> On 14. May 2020, at 09:37, Nov Matake  =
 wrote:
> =20
> Hi,
> =20
> Why not allowing public clients use "other suitable mechanisms=E2=80=9D =
then?
> OAuth WG can allow both type of clients do so, then OIDF will define =
nonce as the alternative only for confidential clients.
> =20
> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =
 =
=E3=81=AE=E3=83=A1=E3=83=
=BC=E3=83=AB:
> =20
> Hi all,
> =20
> I would also like to thank everybody for the substantial discussion. =20=

> =20
> The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:
> =20
> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of =
PKCE instead of requiring it (with a well-defined exception).
> - Given the latest findings re nonce I don=E2=80=99t feel comfortable =
with recommending any mechanism that this WG is not responsible for and =
thus did not conduct the security threat analysis for. I think the =
better way for us as WG is to define the extension point for other =
mechanisms. The OpenID Foundation (or any other body) can then fill in =
and issue a statement that nonce (or another suitable mechanism) fulfils =
the requirements of the extension point.=20
> =20
> Based on this considerations, I propose the following text for Section =
9.7:
> =20
> Clients MUST prevent injection (replay) of authorization codes into=20
> the authorization response by attackers. Public clients MUST use the=20=

> "code_challenge=E2=80=9D with a transaction-specific value that is =
securely=20
> bound to the client and the user agent in which the transaction was=20
> started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=
=9D in the=20
> same way or other suitable mechanisms to mitigate authorization code=20=

> injection.
> =20
> This text follows the logic in Section 4.1.2.1 and allows use of the =
nonce for confidential clients.
> =20
> best regards,
> Torsten.=20
> =20
> On 12. May 2020, at 02:21, Mike Jones =
 =
 wrote:
> =20
> That works for me.  Thanks all for the useful back-and-forth that got =
us to this point of clarity.  I suspect many of us learned things along =
the way; I know that I did!
> =20
>                                                     Cheers,
>                                                     -- Mike
> =20
> From: Aaron Parecki  
> Sent: Monday, May 11, 2020 4:55 PM
> To: OAuth WG  
> Cc: Neil Madden  =
; Mike Jones=20
>  
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
> =20
> Thank you Neil.
> =20
> To address Mike's concerns in the previous threads, I would like to =
also update section 9.7 with the following text:
> =20
> Clients MUST prevent injection (replay) of authorization codes into=20
> the authorization response by attackers. The use of the=20
> `code_challenge` parameter is RECOMMENDED to this end. For=20
> confidential clients, the OpenID Connect `nonce` parameter and ID=20
> Token Claim {{OpenID}} MAY be used instead of or in addition to the=20
> `code_challenge` parameter for this purpose. The `code_challenge`=20
> or OpenID Connect `nonce` value MUST be transaction-specific and=20
> securely bound to the client and the user agent in which the =
transaction was started.
> =20
> This change better clarifies the specific circumstances under which =
the "nonce" parameter is sufficient to protect against authorization =
code injection.
> =20
> Aaron Parecki
> =20
> On Mon, May 11, 2020 at 11:55 AM Neil Madden =
  wrote:
> I am happy with this proposed wording. Thanks for updating it.
> =20
> =E2=80=94 Neil
> =20
> =20
> On 11 May 2020, at 19:52, Aaron Parecki  =
 wrote:
> =20
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20
> =20
> We would like to propose the following text, which is a slight =
variation from the text Neil proposed. This would replace the paragraph =
in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1 =
)=
 that begins with "If the client does not send the "code_challenge" in =
the request..."
> =20
> "An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there =
is reasonable assurance that the client mitigates authorization code =
injection in other ways.. See section 9.7 for details."
> =20
> Section 9.7 is where the nuances of PKCE vs nonce are described.
> =20
> As Neil described, we believe this will allow ASs to support both =
OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is =
the clarification of which threats, and changing to MUST instead of =
SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we =
are already describing the explicit exception to the rule, it's more =
clear as a MUST here.
> =20
> Aaron Parecki
> =20
> =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 =

> _______________________________________________
> 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=_38D4029F-2775-4A23-A7FF-1CFBA72E2474
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes.

The root =
problem isn=E2=80=99t the mix-use of PKCE and nonce, it=E2=80=99s PKCE =
implementation bug.
Yeah, all PKCE =
implementation MUST reject such requests, regardless it=E2=80=99s OAuth =
2.1 or 2.0.

(and =
it=E2=80=99s probably because of PKCE spec=E2=80=99s ambiguity..)

2020/05/20 1:13=E3=80=81Mike Jones <Michael.Jones@microsoft.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3=
=83=AB:

So it sounds me like the fix =
is to have servers reject PKCE requests with incomplete parameter sets: =
requests that only contains one of code_challenge and =
code_verified.  Will that eliminate the attack, Nov?
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of Nov Matake
Sent: Monday, May 18, 2020 11:50 =
PM
To: Daniel Fett <fett@danielfett.de>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] proposed =
resolution for PKCE in OAuth 2.1
 
Sure, feel free to add the senario to =
your post.
 
FYI:
my OAuth2 server ruby gem rejects such token requests,
and Google also does the =
same.
https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046
So I'm guessing such behavior is =
relatively rare-case, hopefully.
 
iPad=E3=81=8B=E3=82=89=E9=80=81=E4=BF=A1


2020/05/19 15:43=E3=80=81Daniel Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
=EF=BB=BF 
Hi,
 
Am 19.05.20 um 04:55 schrieb Nov Matake:
I thought =
the server MUST reject such token requests, but I couldn=E2=80=99t find =
such definition in RFC7636...
 
> The client will send the =
code, along with a (now not matching) code_verifier to the server. The =
server will ignore the code_verifier (as it was not expected) and send =
back an access token and ID token to the client.
 
If the behavior is acceptable by =
RFC7636, "Nonce/PKCE Sidestep Attack=E2=80=9D would be possible.
I *think* that there is nothing preventing servers from =
sometimes using PKCE and sometimes using Nonce. I assume that this is =
out of the scope of the existing specifications.
I would be interested to hear how =
actual implementations handle this in practice.
 
Plus, with such AS behavior, CSRF protection using PKCE can =
also be bypassed as below.
1. The attacker removes =
code_challenge from his/her own AuthZ Req, receives a =
non-code_challenge-bound code, and sends it to the victim.
2. The client receives the attacker=E2=80=99s code from the =
victim, and sends it to the AS w/ the valid code_verifier bound to the =
victim=E2=80=99s browser session.
3. The AS ignores the =
code_verifier and returns tokens.
 
If that=E2=80=99s the case, current OAuth 2.0 PKCE =
implementation can be weaker than expected..
Excellent point!
Would =
it be okay if I add that attack to the original post (with credits, of =
course)?
-Daniel
 
nov


2020/05/19 1:54=E3=80=81Daniel Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
 
Hi all,
 
Talking to Torsten, we realized that =
providing a generic extension point here is probably not a good idea. It =
is really hard to tell what protects you from code injection and what =
does not, and people might come up with all sorts of non-standard and =
potentially insecure solutions. 
 
Even just for PKCE vs. Nonce, it is not =
obvious if they provide the same level of protection. In an attempt to =
answer this question, I tried to come up with a more systematic analysis =
of "PKCE vs Nonce". I wrote up my results here:

Although this is not a formal analysis, I hope =
that I have covered all interesting cases. Please review the text and =
let me know if I have missed something or if there are any mistakes.

The main results are:
  1. In terms =
of protection against CSRF and code misuse, PKCE and Nonce provide =
similar levels of security, with a slight advantage for PKCE.
  2. In =
practice, a circumvention of both mechanisms, however, is possible if an =
AS allows a client to choose between PKCE and Nonce and the client makes =
use of this freedom. I propose to call this attack the Nonce/PKCE =
Sidestep Attack. =E2=86=92 Please review the attack description in the =
analysis.
  3. To avoid the Nonce/PKCE Sidestep Attack, clients =
must not switch between using only PKCE and only Nonce (but may use both =
in parallel, or switch between using only PKCE and PKCE+Nonce). =
Authorization servers must enforce PKCE unless they know that the client =
uses Nonce for all of its flows (and checks the Nonce value). The =
presence of a nonce parameter in the authorization request is not =
sufficient to determine if a client actually checks the nonce claim in =
the ID token.
As you can see, already having two more-or-less =
well-understood mechanisms is hard enough to wrap your head around from =
a security standpoint. We should therefore make PKCE the default and =
Nonce an option for backwards compatibility.
To this =
end, I would like to propose the follwing strawman, based on Torsten's =
and Aaron's suggestions:
An AS MUST reject =
requests without a code_challenge from public
clients, and MUST reject such requests from other =
clients unless there
is reasonable assurance that the =
client mitigates authorization code
injection =
using the OpenID Connect Nonce mechanism and that this
mitigation is used for all interactions with the client. See =
section
9.7 for details.

Section 9.7:

Clients MUST prevent injection =
(replay) of authorization codes into
the =
authorization response by attackers. The use of the
`code_challenge` parameter is RECOMMENDED to this end. =
For
confidential clients, the OpenID Connect `nonce` =
parameter and ID
Token Claim {{OpenID}} MAY be used =
instead of or in addition to the
`code_challenge` parameter for this purpose. The =
`code_challenge` or
OpenID Connect `nonce` value MUST =
be transaction-specific and securely
bound to the =
client and the user agent in which the transaction was
started.

If the OpenID =
Connect `nonce` is used to mitigate authorization code
injection instead of `code_challenge`, client and =
authorization server
MUST ensure that the mitigation is =
applied to every interaction with
the client =
and that the client cannot switch between `code_challenge`
and `nonce`. For example, the presence of a `nonce` parameter =
in the
authorization request is not sufficient to =
determine that the
`code_verifier` check can be =
skipped.
 
Of course, we need to adapt the wording in the Security BCP =
accordingly.
-Daniel
 
 
Am 15.05.20 um 01:01 schrieb Mike Jones:
I =
agree with Nov that obscuring the language in 9.7 would be a disservice =
to developers.
 
The Security BCP, which has already going the WGLC, =
explicitly calls out the use of nonce as part of the best =
practices.  OAuth 2.1 should do no less.
 
The =
9.7 language that Aaron proposed was the result of many people's =
contributions and a vigorous discussion.  Let's publish the next =
version of 2.1 with that language intact, as I believe it represents at =
least a local point of hard-won consensus.  Let's get that language =
into the record of drafts.
 
There's=
 always time to debate it and change it later in subsequent drafts, but =
let's not now lose what it took a lot of effort to achieve.
 
    =
Thanks,
    -- Mike
 
-----Original Message-----
From: =
Nov Matake <matake@gmail.com> =

Sent: =
Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: =
OAuth WG <oauth@ietf.org>; Mike =
Jones <Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth =
2.1
 
There =
is no specific mechanism right now.
But future developers won=E2=80=99t =
be able to read the reason why the extension point is given only for =
confidential clients.
 
On May 14, 2020, at 18:32, Torsten =
Lodderstedt <torsten@lodderstedt.net> wrote:
 
Are =
you aware of any suitable mechanism? I=E2=80=99m asking since from my =
perspective this clause is mainly intended to allow existing OpenID =
Connect deployments to use nonce instead of PKCE in combination with =
OAuth 2.1. It=E2=80=99s a compromise. I think we should not encourage =
others to invent their own OAuth security mechanisms. 
 
On =
14. May 2020, at 09:37, Nov Matake <matake@gmail.com> wrote:
 
Hi,
 
Why =
not allowing public clients use "other suitable mechanisms=E2=80=9D =
then?
OAuth =
WG can allow both type of clients do so, then OIDF will define nonce as =
the alternative only for confidential clients.
 
2020/05/14 15:56=E3=80=81Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
 
Hi =
all,
 
I =
would also like to thank everybody for the substantial discussion.  =

 
The =
proposed change for Section 4.1.2.1 works for me (as already stated). =
I=E2=80=99m not fully comfortable with the proposed change for Section =
9.7 for the following reasons:
 
- The =
text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE =
instead of requiring it (with a well-defined exception).
- =
Given the latest findings re nonce I don=E2=80=99t feel comfortable with =
recommending any mechanism that this WG is not responsible for and thus =
did not conduct the security threat analysis for. I think the better way =
for us as WG is to define the extension point for other mechanisms. The =
OpenID Foundation (or any other body) can then fill in and issue a =
statement that nonce (or another suitable mechanism) fulfils the =
requirements of the extension point. 
 
Based =
on this considerations, I propose the following text for Section =
9.7:
 
Clients=
 MUST prevent injection (replay) of authorization codes into 
the =
authorization response by attackers. Public clients MUST use the 
"code_challenge=E2=80=9D with a transaction-specific value =
that is securely 
bound to the client and the user agent in which the =
transaction was 
started. Confidential clients MUST use the =
=E2=80=9Ccode_challenge=E2=80=9D in the 
same way or other suitable =
mechanisms to mitigate authorization code 
injection.
 
This =
text follows the logic in Section 4.1.2.1 and allows use of the nonce =
for confidential clients.
 
best regards,
Torsten. 
 
On 12. May 2020, at 02:21, Mike =
Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> =
wrote:
 
That works for me.  Thanks all for the useful =
back-and-forth that got us to this point of clarity.  I suspect =
many of us learned things along the way; I know that I did!
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;    Cheers,
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;    -- Mike
 
From: =
Aaron Parecki <aaron@parecki.com>
Sent: =
Monday, May 11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
Cc: =
Neil Madden <neil.madden@forgerock.com>; Mike Jones 
<Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth =
2.1
 
Thank =
you Neil.
 
To address Mike's concerns in the previous threads, I would =
like to also update section 9.7 with the following text:
 
Clients=
 MUST prevent injection (replay) of authorization codes into 
the =
authorization response by attackers. The use of the 
`code_challenge` parameter is RECOMMENDED to this end. For =

confidential clients, the OpenID Connect `nonce` parameter =
and ID 
Token Claim {{OpenID}} MAY be used instead of or in addition =
to the 
`code_challenge` parameter for this purpose. The =
`code_challenge` 
or OpenID Connect `nonce` value MUST be transaction-specific =
and 
securely bound to the client and the user agent in which the =
transaction was started.
 
This change better clarifies the =
specific circumstances under which the "nonce" parameter is sufficient =
to protect against authorization code injection.
 
Aaron =
Parecki
 
On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.madden@forgerock.com> wrote:
I am =
happy with this proposed wording. Thanks for updating it.
 
=E2=80=94=
 Neil
 
 
On 11 =
May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> wrote:
 
Thanks =
for the lively discussion around PKCE in OAuth 2.1 everyone! 
 
We =
would like to propose the following text, which is a slight variation =
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 =
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section=
-4.1.2.1) that begins with "If the client does not send the =
"code_challenge" in the request..."
 
"An =
AS MUST reject requests without a code_challenge from public clients, =
and MUST reject such requests from other clients unless there is =
reasonable assurance that the client mitigates authorization code =
injection in other ways.. See section 9.7 for details."
 
Section=
 9.7 is where the nuances of PKCE vs nonce are described.
 
As =
Neil described, we believe this will allow ASs to support both OAuth 2.0 =
and 2.1 clients simultaneously. The change from Neil's text is the =
clarification of which threats, and changing to MUST instead of SHOULD. =
The "MUST...unless" is more specific than "SHOULD", and since we are =
already describing the explicit exception to the rule, it's more clear =
as a MUST here.
 
Aaron Parecki
 
 
 
 
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth =
mailing 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=_38D4029F-2775-4A23-A7FF-1CFBA72E2474--


From nobody Wed May 20 05:07:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9158B3A082E for ; Wed, 20 May 2020 05:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UARxBvjyQUXB for ; Wed, 20 May 2020 05:07:21 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B7F3A081F for ; Wed, 20 May 2020 05:07:21 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id d26so2212875otc.7 for ; Wed, 20 May 2020 05:07:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=zx3SkSH1eOdFwyuPC162SmQcoZ6m8PiRkcvkqitlHRg=; b=TK3Rt+Sr6Va0gY9zy6/T0hDjXCjb6n9uX2HYktmGvNJ1lH0nBXnaWsVlYIl4aDTiHB KDibHHtbi8F6JB/Ji7IZGjwZjZuxXQQ0UUaAc2eEFUy1UN4zpfXc3LkVGWdVCnw453Ky 8BJiz4tXZ8rELt2QOI/re2Ai30BAwUv6f6fvc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zx3SkSH1eOdFwyuPC162SmQcoZ6m8PiRkcvkqitlHRg=; b=BeBQ7lCQUAEUkZFuu1V1xMPYqTZA6azv9kQvunJbXje8uMP2Y9n7ZUDlUUVqxuEeIn Jv0BgF5cHeamHuEe71PEu/pNlWINs9HMqbkQuM1RHvJKhefammVlMDCr66XsWpS6HiIr pz42Ohz+K0tYDm7M8YgzXQe0ZhOt7/xhUN83jfTZrmhKK7rpSD4UoMTuzchyxvWKQZZi mwVxBeqIZ3LAt1EJdYPU+PwFuDdA2VsDe5J/1319rpaaglVykYmpTaWZsnDObrXVrNHu e3bi8s86OOgoXreNzzOsY5FEUuH5oW28RyBreJQJHGwrFZkPVV4CNfkUxmHC4zHoNoJy 2biQ==
X-Gm-Message-State: AOAM533wO8gQxv7GAhxNr3yBjUpCn8DgPB7SRLfLzlmn/zqUPhlt0dW4 yRAdW3UGjQ0x1oi4oh7wMSGBgtTf1JlI+OoULLZ3hzbqOcwMZYqa
X-Google-Smtp-Source: ABdhPJy7+LnKFeb1QR21PTlu3UXZfPPsFTUUNR4aQIptfdvg2xdRbGgRuqRCjpNjqeK4MBGA0Ra5QkIj4DVG9Z8bkk8=
X-Received: by 2002:a9d:20e7:: with SMTP id x94mr3106958ota.260.1589976440496;  Wed, 20 May 2020 05:07:20 -0700 (PDT)
MIME-Version: 1.0
From: Dave Tonge 
Date: Wed, 20 May 2020 14:07:09 +0200
Message-ID: 
To: oauth 
Cc: Joseph Heenan ,  Openid-specs Fapi 
Content-Type: multipart/alternative; boundary="000000000000f00f8005a6133cea"
Archived-At: 
Subject: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 May 2020 12:07:24 -0000

--000000000000f00f8005a6133cea
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear OAuth WG

We have an issue

in the OpenID FAPI Working Group that we believe affects the wider OAuth
community.

In summary: *what is the recommended approach to discovery (RFC8414) for
Authorization Servers who support multiple "brands" .*

If brands are completely separate, then it seems sensible that each brand
must have its own `issuer` and therefore its own discovery document at the
correct location (i.e. brand 1 would have an issuer of "https://as/brand1"
and a discovery document available at  https://as/.well-known/
oauth-authorization-server/brand1).

However in the real world it is not always so simple. We have many existing
implementations in UK open banking that support multiple authorization
endpoints. Here is an example (thanks to @Joseph Heenan
 )

> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet banking,=
 one =E2=80=9Clogin
page=E2=80=9D for both business and personal customers.

> They have separate mobile apps for business/personal, and are required to
support app2app. This means they will definitely be exposing multiple
authorization endpoints (as there=E2=80=99s a 1:1 mapping of authorization
endpoints to mobile apps) - the choice is how they do this.

> Their choices are:

> 1. Multiple discovery endpoints (one for business, one for personal),
each with a different authorization endpoint, multiple issuers (if their
vendor allows this)
> 2. Single discovery endpoint, single issuer, multiple authorization
endpoints listed in one discovery doc (one for business, one for personal)
some of which are hardcoded by the 3rd party
> 3. Multiple discovery endpoints each with a different authorization
endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)

Option 3 is invalid and that leaves us with options 1 and 2.
Option 1 can be problematic as often it is in reality the same `issuer`
behind the scenes.

We would like to get feedback on this issue and potentially an extension to
RFC8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG
Open ID Foundation

--000000000000f00f8005a6133cea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear OAuth WG

We have an =
issue in the OpenID FAPI Working Group that we believe affects the wide=
r OAuth community.

In summary: what is the recommended ap=
proach to discovery (RFC8414) for Authorization Servers=C2=A0who support mu=
ltiple "brands" .

If brands are completely sep=
arate, then it seems sensible that each brand must have its own `issuer` an=
d therefore its own discovery document at the correct location (i.e. brand =
1 would have an issuer of "https://as/br=
and1" and a discovery document available at=C2=A0 https://as/.well-known/oauth-autho=
rization-server/brand1).

However in the real world it is not always so simple. We have =
many existing implementations in UK open banking that support=C2=A0multiple=
 authorization endpoints. Here is an example (thanks to=C2=A0@Joseph Heenan=C2=A0)

> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp =
and, for internet banking, one =E2=80=9Clogin page=E2=80=9D for both busine=
ss and personal customers.

> They have separate mobile apps for b=
usiness/personal, and are required to support app2app. This means they will=
 definitely be exposing multiple authorization endpoints (as there=E2=80=99=
s a 1:1 mapping of authorization endpoints to mobile apps) - the choice is =
how they do this.

> Their choices are:

> 1. Multiple di=
scovery endpoints (one for business, one for personal), each with a differe=
nt authorization endpoint, multiple issuers (if their vendor allows this)> 2. Single discovery endpoint, single issuer, multiple authorization =
endpoints listed in one discovery doc (one for business, one for personal) =
some of which are hardcoded by the 3rd party
> 3. Multiple discovery =
endpoints each with a different authorization endpoint, same issuer in all =
cases (breaks RFC8414 and OIDC Discovery)

Option 3 is invalid and that leaves us with options 1 and 2.=C2=A0<=
/div>
Option 1 can be problematic as often it is in reality the =
same `issuer` behind the scenes.

We =
would like to get feedback on this issue and potentially an extension to RF=
C8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG



--000000000000f00f8005a6133cea--


From nobody Wed May 20 07:17:34 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3CB3A0A3A for ; Wed, 20 May 2020 07:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1qGGqFyY8Fl for ; Wed, 20 May 2020 07:17:21 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B66A3A0A13 for ; Wed, 20 May 2020 07:17:20 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id f134so2697680wmf.1 for ; Wed, 20 May 2020 07:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=63lGvsAvBfm0nf4q9im9RT2sRibJDCrXL4vYAtLXclg=; b=lbodHIX2HwSGUy4Q2PawF8HB25eaaKjN/7ZHyf5YcoNouVWqJVLe46aoLj0+rW1WiR xVjaICv/mBIn/lBObyPwBmXTny5EPhlCnBUr/Yafee4EtMr+QIQ+E6QqOmKZuP+N/Q+F hnjwh+ENshuHv5ctdaV6qhLAxzlu84SZg+4BYCYdhKyEsa3RbQJnhfczgYHVy7wwhdXT Lt3EelDLUkBEWkwBd7SaGaU/bZPmS5pD674PDd7X6arR3xsvf7OL6C2zVJ3f4+BgweHe vCz0kLj/ruJETTuMimGc0E24ObEZhZMJYQXxNRm/DlOmuGMXbWLTSEQeaAax/LrN4xjU gj/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=63lGvsAvBfm0nf4q9im9RT2sRibJDCrXL4vYAtLXclg=; b=gWxg9pwfcLw0wexpMs9OhY2cpAZ7PuauXlGwLf4ajwz1lvmDw3RI779dPuzUKB2Q+y XolIo545a56f7v7kZ3z2zBFNvYVNHGx78AQABQOAtEwnPQMHJt1ceSt67+gLODmXeeg7 hcxlGpgBvA/1fY2u5dzU+yLUhYjRH4ZLXKZF7NJVvGVTnxEJxadS6a9lRxNUTE9nfj26 M7wO93ft0b+Q8jYwyh95FKtXKatcQaHuu5V9FqWssgkJXJO0S4leJkxsE+3DKRyca4lJ p/r5Hn+vcZ2rI6gOA1qiZYj28gpT2tQbtYebkLVU/U4cmaj7R1EJ0iE4KvrO4buWHstm M2xA==
X-Gm-Message-State: AOAM531Pcj05DYfvvexrHoMUsDxxjN1lvfCazaOD6O4wRtqu2azQk55C gbdxYZ7N78mLmv+F47weopnVAovQ0OpB//QDLZ4=
X-Google-Smtp-Source: ABdhPJyK8qwIJmwmohCQ7jJJ8jySOCo/BEluzwSvXamlBMe2u8gXc88wczKdwKBBWs5JZNqlCNizOWwI7LiAVnSh6Hg=
X-Received: by 2002:a1c:4d17:: with SMTP id o23mr4800089wmh.87.1589984238979;  Wed, 20 May 2020 07:17:18 -0700 (PDT)
MIME-Version: 1.0
References: <158937215806.9148.1182768951394743318@ietfa.amsl.com>   
In-Reply-To: 
From: Janak Amarasena 
Date: Wed, 20 May 2020 19:46:42 +0530
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000c34e0105a6150df3"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 May 2020 14:17:30 -0000

--000000000000c34e0105a6150df3
Content-Type: text/plain; charset="UTF-8"

Hi Rifaat,

Any chance of getting the recording of the meeting?

Best Regards,
Janak Amarasena

On Tue, May 19, 2020 at 3:40 PM Rifaat Shekh-Yusef 
wrote:

> Hi Filip,
>
> I have uploaded the slides to the materials page here:
>
> https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop
> 
>
>
> Regards,
>  Rifaat
>
>
> On Tue, May 19, 2020 at 5:39 AM Filip Skokan  wrote:
>
>> Hello Brian,
>>
>> can you share the slide deck from yesterday so that we may continue
>> the discussion on the mentioned open questions here on the list?
>>
>> Thank you,
>>
>> Best,
>> *Filip*
>>
>>
>> On Wed, 13 May 2020 at 20:43, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote:
>>
>>> Just wanted to note that there is a newer -01 revision of the document
>>> on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>>>
>>> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
>>> wrote:
>>>
>>>> The Web Authorization Protocol (oauth) Working Group will hold
>>>> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00
>>>> Europe/Vienna (16:00 to 17:00 UTC).
>>>>
>>>> Agenda:
>>>> DPOP
>>>> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>>>>
>>>> Information about remote participation:
>>>> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>>>>
>>>> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>>>>
>>>> _______________________________________________
>>>> IETF-Announce mailing list
>>>> IETF-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly
>>> prohibited....  If you have received this communication in error, please
>>> notify the sender immediately by e-mail and delete the message and any file
>>> attachments from your computer. Thank you.*
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000c34e0105a6150df3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0Rifaat,

Any chance of getting t=
he recording of the meeting?

Best Regards,
Janak Amarasena

On Tue, May 19, 2020 at 3:40 PM Rifaat Shekh-Yusef =
<rifaat.s.ietf@gmail.com&=
gt; wrote:
Hi Filip,

I have uploaded the slides to the =
materials page here:
<=
div>
Regards,
=C2=A0Rifaat
=C2=A0

On Tue, May 19, 2020 at 5:39 AM Filip Skokan <panva.ip@gmail.com> wrote:
=

Hello Br=
ian,

can you share the slide deck from yesterday so that=
 we may continue the=C2=A0discussion on the mentioned open questions here o=
n the list?

Thank you,

Best,
Filip

On Wed, 1=
3 May 2020 at 20:43, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ie=
tf.org> wrote:
Just wanted to note that there is a newer -01 revisi=
on of the document on the agenda https://www.ietf.org/id/draft-iet=
f-oauth-dpop-01.html 

On Wed, May 13, 2020 at 6:16 AM IESG Secretar=
y <iesg-sec=
retary@ietf.org> wrote:
The Web Authorization Protocol (oauth) Working Group will ho=
ld

a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna (=
16:00 to 17:00 UTC).



Agenda:

DPOP

https://tools.ietf.org/html/draft-ietf-oauth-dpo=
p-00



Information about remote participation:

https://ietf.webex.com/iet=
f/j.php?MTID=3Dm2655406e74aa2b4e129a1b91a076f70b



https://mailarchive.ietf.org=
/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/



_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announ=
ce






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
....=C2=A0 If you have received this communication in error, please notify =
the sender immediately by e-mail and delete the message and any file attach=
ments from your computer. Thank you._____________________=
__________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000c34e0105a6150df3--


From nobody Wed May 20 07:23:26 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835DC3A0A22 for ; Wed, 20 May 2020 07:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKXAJ5YJS9Xn for ; Wed, 20 May 2020 07:23:22 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A99A3A0A21 for ; Wed, 20 May 2020 07:23:21 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id j5so3379414wrq.2 for ; Wed, 20 May 2020 07:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ADg1ExJ7Dgpf312sEzA/l2SDv48gQvLqPnzqKiF5x7g=; b=rVG4aQmj9eLmcfP4ROw5IENU53bTXblvspfFr6GwEhXjsGam18qerngldXS59yD5BY mHP+DULSdRTbFR8kIfYj+y6LLXrlSinhV3xC8KMFPC8q8lqBmnV7bvlqt2s46RCVZ68k BFsfzd0T5v0K3gkRsRhTHQ5SpCqPQUKriZpSC97VwewGAwlbhu3PExgjBtcyG6Xhul7j l/SMso8gYAY+GPpn1j0HyeJdy6fvnkiin5gpxqQUJZk7zCMxWR+rK/7aMUs5uD/jhFAn TdCYKHgVT1MhM6zn6Bo8H26pnIUiw7YzIpiGfrX4HxHHrPQ0gxFNv4BVBCZq11gmNuwL wVHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ADg1ExJ7Dgpf312sEzA/l2SDv48gQvLqPnzqKiF5x7g=; b=hNGJSLAT3m2EspNaCdOkoiRtV/lUh5LhlK9o3I19DLk3SDRbdHLtM88rXQQrefCS8z dfufET2YWPVG9K/HIFRVCUNN6LyY8rTxl4uKheUy7q37wUywO8307GawPfcqkTWuXg7I g49Kabuo6pR3mjqbKeEzpzMxigg+RQ4YaFRciQfYQE8mhq5iKK6b5DHZEDYIH8gx3M3U hskL8ebsdlhlJvrED4vgEAVtWbAZgmF5tNzQkCZTZbmlogOCT+qL+5kYu1Cs/VI0dHHc EhUZLh3s0Uzd8QEcMi9coloV+FTUcjYLm3NNa9VXIdLAYbcdaAF3wpUcbWUHoIYoamfn COmQ==
X-Gm-Message-State: AOAM533rY07XwV9iy16rJf56bOk7Fs3bu/RLfcd9Pn8c3ypu4FW+WPny qD/mc0BqhhOA1lYAMT7hifJbSB53SRrQQYkEvhk=
X-Google-Smtp-Source: ABdhPJyDfxYhaGvbEWMKxGfD+fn7BUpkOwpL1wqS8sqJNUVXHsjo29a4y+kHismXZb4IfivAATcWAS0KuumgOzCuHTY=
X-Received: by 2002:adf:9286:: with SMTP id 6mr4677898wrn.179.1589984600322; Wed, 20 May 2020 07:23:20 -0700 (PDT)
MIME-Version: 1.0
References: <158937215806.9148.1182768951394743318@ietfa.amsl.com>    
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Wed, 20 May 2020 10:23:10 -0400
Message-ID: 
To: Janak Amarasena 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000004cf80705a61523f4"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 May 2020 14:23:25 -0000

--0000000000004cf80705a61523f4
Content-Type: text/plain; charset="UTF-8"

Hi Janak,

All interim meetings are posted on the IETF Youtube channel.
Here is the link to the latest meeting:
https://www.youtube.com/watch?v=txkRiIiHEbE

Regards,
 Rifaat


On Wed, May 20, 2020 at 10:17 AM Janak Amarasena 
wrote:

> Hi Rifaat,
>
> Any chance of getting the recording of the meeting?
>
> Best Regards,
> Janak Amarasena
>
> On Tue, May 19, 2020 at 3:40 PM Rifaat Shekh-Yusef <
> rifaat.s.ietf@gmail.com> wrote:
>
>> Hi Filip,
>>
>> I have uploaded the slides to the materials page here:
>>
>> https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop
>> 
>>
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Tue, May 19, 2020 at 5:39 AM Filip Skokan  wrote:
>>
>>> Hello Brian,
>>>
>>> can you share the slide deck from yesterday so that we may continue
>>> the discussion on the mentioned open questions here on the list?
>>>
>>> Thank you,
>>>
>>> Best,
>>> *Filip*
>>>
>>>
>>> On Wed, 13 May 2020 at 20:43, Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote:
>>>
>>>> Just wanted to note that there is a newer -01 revision of the document
>>>> on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>>>>
>>>> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
>>>> wrote:
>>>>
>>>>> The Web Authorization Protocol (oauth) Working Group will hold
>>>>> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00
>>>>> Europe/Vienna (16:00 to 17:00 UTC).
>>>>>
>>>>> Agenda:
>>>>> DPOP
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>>>>>
>>>>> Information about remote participation:
>>>>>
>>>>> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>>>>>
>>>>>
>>>>> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>>>>>
>>>>> _______________________________________________
>>>>> IETF-Announce mailing list
>>>>> IETF-Announce@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>>
>>>>
>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>> privileged material for the sole use of the intended recipient(s). Any
>>>> review, use, distribution or disclosure by others is strictly
>>>> prohibited....  If you have received this communication in error, please
>>>> notify the sender immediately by e-mail and delete the message and any file
>>>> attachments from your computer. Thank you.*
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--0000000000004cf80705a61523f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Janak,

All interim meetings are post=
ed on the IETF Youtube=C2=A0channel.
Here is the=C2=A0link to the=
 latest meeting:

Regards,
=C2=A0Rifaat
=C2=A0
<=
/div>
O=
n Wed, May 20, 2020 at 10:17 AM Janak Amarasena <janakama360@gmail.com> wrote:
Hi=C2=A0Rifaat,
Any chance of getting the recording of the meeting?

Best Regards,
Janak Amarasena

On Tue, May =
19, 2020 at 3:40 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
Hi Fil=
ip,

I have uploaded the slides to the materials page her=
e:

Regards,
=C2=A0Rifaat
=C2=A0

On Tue, May 19, =
2020 at 5:39 AM Filip Skokan <panva.ip@gmail.com> wrote:
Hello Brian,

can you share the slide deck from yesterday so that we may continue =
the=C2=A0discussion on the mentioned open questions here on the list?
=


Thank you,

Best,
Filip


On Wed, 13 May 2020 at 20:=
43, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wr=
ote:
Just wanted to note that there is a newer -01 revision of the documen=
t on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.h=
tml 

On Wed, May 13, 2020 at 6:16 AM IESG Secretary <iesg-secretary@ietf.org> wrote:
The=
 Web Authorization Protocol (oauth) Working Group will hold

a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna (=
16:00 to 17:00 UTC).



Agenda:

DPOP

https://tools.ietf.org/html/draft-ietf-oauth-dpo=
p-00



Information about remote participation:

https://ietf.webex.com/iet=
f/j.php?MTID=3Dm2655406e74aa2b4e129a1b91a076f70b



https://mailarchive.ietf.org=
/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/



_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announ=
ce






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
....=C2=A0 If you have received this communication in error, please notify =
the sender immediately by e-mail and delete the message and any file attach=
ments from your computer. Thank you._____________________=
__________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000004cf80705a61523f4--


From nobody Wed May 20 08:08:21 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11A3A0A81 for ; Wed, 20 May 2020 08:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVSuqwaqSwZ7 for ; Wed, 20 May 2020 08:08:01 -0700 (PDT)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 B55853A093D for ; Wed, 20 May 2020 08:08:01 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id bQK5j3BGtdUjIbQK7j1Ei5; Wed, 20 May 2020 08:08:01 -0700
X-CMAE-Analysis: v=2.3 cv=V4wDLtvi c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=xtERp6CFAAAA:8 a=uXKtHWO2UFqTaMCM4KwA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=eD4XPYFH_YmTrwKq:21 a=LPvUBouTuPz367Qt:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=iwW7FXZmUZ5ra3T_uI4A:9 a=sOIWAApBRbf-zHzR:21 a=rjHpS40FXzfAw-er:21 a=LcEjaFlFgROdAWtY:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Dave Tonge , oauth 
Cc: Openid-specs Fapi , Joseph Heenan 
References: 
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com>
Date: Wed, 20 May 2020 18:07:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000001050600080908000600"
X-CMAE-Envelope: MS4wfAFUYL8gSwL54//Al7lHqmqKsidE7xfhhc6yDZuCc3wg/uNLoklDm9YWExX2XcJjLCsB0fWFJ1m5KXabDKxZfznhCUBknS391ztVWxkh6FGsvyaXZ7f6 HobZ8Ta5kaMuVxyHWvSkWP/eqXSAYCQHis7H1jklgz33luJQfcIzCSCitucnQ8/WH+JhMkCdU9QuvHmYfIbQ0KS2Z0aTMY5tS2v8GQ8Z26Iam2PdWqKGsB1I 15vfN6YdOv4pfux+HdF87+V9qvenfxuV515NkPqfOS1PbLgGleS3tbhZtiQCoJYARlEiz6QDFTo9hVtuH9fwog==
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 May 2020 15:08:05 -0000

This is a cryptographically signed message in MIME format.

--------------ms000001050600080908000600
Content-Type: multipart/alternative;
 boundary="------------53EFBE2A5C5F5BDF1A799981"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------53EFBE2A5C5F5BDF1A799981
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Dave,

In the absence of such a "multi-brand" spec we have tackled this issue
in the past by letting the "brand" be encoded in the client_id. An
alternative scenario is to do a "brand" lookup by client_id. Then let
the AS render the "branded" authZ endpoint.

You're probably aware the mTLS spec is allowing for endpoint aliases, so
this is not the first time such as need has occurred:

https://tools.ietf.org/html/rfc8705#section-5

One could devise a similar JSON object with mappings "label" -
"authorization_endpoint".

Clients that are aware of the new spec will look it up, those that are
not will fall back to the std "authorization_endpoint".

Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be
sensibly combined with the proposed multi-brand spec.


Vladimir


On 20/05/2020 15:07, Dave Tonge wrote:
> Dear OAuth WG
>
> We have an issue
> 
> in the OpenID FAPI Working Group that we believe affects the wider
> OAuth community.
>
> In summary: *what is the recommended approach to discovery (RFC8414)
> for Authorization Servers=C2=A0who support multiple "brands" .*
>
> If brands are completely separate, then it seems sensible that each
> brand must have its own `issuer` and therefore its own discovery
> document at the correct location (i.e. brand 1 would have an issuer of
> "https://as/brand1" and a discovery document available at=C2=A0
> https://as/.well-known/oauth-authorization-server/brand1).
>
> However in the real world it is not always so simple. We have many
> existing implementations in UK open banking that support=C2=A0multiple
> authorization endpoints. Here is an example (thanks to=C2=A0@Joseph Hee=
nan
> =C2=A0)
>
> > Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet bank=
ing, one =E2=80=9Clogin
> page=E2=80=9D for both business and personal customers.
>
> > They have separate mobile apps for business/personal, and are
> required to support app2app. This means they will definitely be
> exposing multiple authorization endpoints (as there=E2=80=99s a 1:1 map=
ping of
> authorization endpoints to mobile apps) - the choice is how they do thi=
s.
>
> > Their choices are:
>
> > 1. Multiple discovery endpoints (one for business, one for
> personal), each with a different authorization endpoint, multiple
> issuers (if their vendor allows this)
> > 2. Single discovery endpoint, single issuer, multiple authorization
> endpoints listed in one discovery doc (one for business, one for
> personal) some of which are hardcoded by the 3rd party
> > 3. Multiple discovery endpoints each with a different authorization
> endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)
>
> Option 3 is invalid and that leaves us with options 1 and 2.=C2=A0
> Option 1 can be problematic as often it is in reality the same
> `issuer` behind the scenes.
>
> We would like to get feedback on this issue and potentially an
> extension to RFC8414 to allow the definition of multiple authorization
> endpoints.
>
> Thanks in advance
>
> Dave Tonge
> Co-Chair FAPI WG
> Open ID Foundation
>
>


--------------53EFBE2A5C5F5BDF1A799981
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Dave,

    
In the absence of such a "multi-brand" spec we have tackled this
      issue in the past by letting the "brand" be encoded in the
      client_id. An alternative scenario is to do a "brand" lookup by
      client_id. Then let the AS render the "branded" authZ endpoint.
=

    
You're probably aware the mTLS spec is allowing for endpoint
      aliases, so this is not the first time such as need has occurred:
    
https://tools.ietf.org/html/rfc8705#section-5=


    
One could devise a similar JSON object with mappings "label" -
      "authorization_endpoint".

    
Clients that are aware of the new spec will look it up, those
      that are not will fall back to the std "authorization_endpoint".
    
Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases"
      can be sensibly combined with the proposed multi-brand spec.

    


    

    
Vladimir

    

    


    

    
On 20/05/2020 15:07, Dave Tonge wrote:=


    

    

      
      

        
Dear OAuth WG

        


        

        
We have an issue in the OpenID FAPI Working=

          Group that we believe affects the wider OAuth community.

        


        

        
In summary: what is the recommended
            approach to discovery (RFC8414) for Authorization
            Servers=C2=A0who support multiple "brands" .

        


        

        
If brands are completely separate, then it
          seems sensible that each brand must have its own `issuer` and
          therefore its own discovery document at the correct location
          (i.e. brand 1 would have an issuer of "https://a=
s/brand1"
          and a discovery document available at=C2=A0 htt=
ps://as/.well-known/oauth-authorization-server/brand1).

        


          

        
However
            in the real world it is not always so simple. We have many
            existing implementations in UK open banking that
            support=C2=A0multiple authorization endpoints. Here is an exa=
mple
            (thanks to=C2=A0@Joseph Heenan=C2=A0)
        


          

        
> Bank =E2=80=9Cloadsamoney=E2=80=9D has one =
idp and, for
          internet banking, one =E2=80=9Clogin page=E2=80=9D for both bus=
iness and
          personal customers.

          

          > They have separate mobile apps for business/personal, and
          are required to support app2app. This means they will
          definitely be exposing multiple authorization endpoints (as
          there=E2=80=99s a 1:1 mapping of authorization endpoints to mob=
ile
          apps) - the choice is how they do this.

          

          > Their choices are:

          

          > 1. Multiple discovery endpoints (one for business, one
          for personal), each with a different authorization endpoint,
          multiple issuers (if their vendor allows this)

          > 2. Single discovery endpoint, single issuer, multiple
          authorization endpoints listed in one discovery doc (one for
          business, one for personal) some of which are hardcoded by the
          3rd party

          > 3. Multiple discovery endpoints each with a different
          authorization endpoint, same issuer in all cases (breaks
          RFC8414 and OIDC Discovery)

        

        


        

        

          
Option 3 is invalid and that leaves us
            with options 1 and 2.=C2=A0

          
Option 1 can be problematic as often it
            is in reality the same `issuer` behind the scenes.

          


          

          
We would like to get feedback on this
            issue and potentially an extension to RFC8414 to allow the
            definition of multiple authorization endpoints.

          


          

          
Thanks in advance

          


          

          
Dave Tonge

          
Co-Chair FAPI WG

          
Open ID Foundation

          


          

        

        


        

      

    

    

  


--------------53EFBE2A5C5F5BDF1A799981--

--------------ms000001050600080908000600
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
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjAxNTA3NTdaMC8G
CSqGSIb3DQEJBDEiBCBtN+m4oQANsNMQy8ifvCEOVwbMfdpPwa7n/PSh1i2kazBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBABK+CV2G9oz14aGhkbL7HNah1lhm4st0AMsV4qcZnU1j/n+1
yeS0Me2oLkeXeNku66WBBBagbl4abcnw4Qvy5a9KT5vtyaieoFJCUlPIfxDB9NbKU1LdrX3k
EMUYKFb0Gsk7FYkyyIBPsS7CRDOOlpgaUBWG9EsvZWDJR/d2LCrhfznnUYEf8azHnSVs9hZN
CJlKsDw7KHg7eUTRx/l80ArD/bACTU9nYobeTl111fxaNPmokOoRa/fOMsJ2zmFYbZTndkqM
U3ZuElr7pIM2zvH7K7PDYQDabUyvMLgNFKgZ/3k+4acNA0heE8LZs567w9G905enMPU9Zbb8
nWbeJwcAAAAAAAA=
--------------ms000001050600080908000600--


From nobody Wed May 20 09:16:54 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2773A0C1A for ; Wed, 20 May 2020 09:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fintechlabs-io.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b67Xx4YpXbqp for ; Wed, 20 May 2020 09:16:49 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8F13A0BBA for ; Wed, 20 May 2020 09:16:48 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id u188so3526679wmu.1 for ; Wed, 20 May 2020 09:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fintechlabs-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YFjtzaSPXZzpKhnINPKLwG8nZSqk8i1PNhxU0gkTj7M=; b=owfrijxlqyZXdRWSaV8v/ogEgCu5vVWPUkcwjgYvY0i6Yzf9iU/5bFPf67j6yz7Aef mIu8ZY2kLbs8XhRZFGk31sZP5y5/OSqGBcKBk2gXWowSz5h9Zr/qEHFA/+IEXXPmLuQp zW5u/m/RETZfwh6AN9CjlD8X/yUbIcwEe16nyFQWeI+xe4Kx5w1u2DJ3rdc7TQ72D6Kb IO6EBBU1gNbFpSHSfACHMLqECKc9arHA3kqxNSf665OJdrVJOis/hiBmgjq5WgxEyAos CQNDo2UrdNi+b6Y3W0lIxAV3VG+h3ZGZyP3K8FZHd3tyD0Hz2Y0FB5eAYrKDQ0X9AfmY 1iGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YFjtzaSPXZzpKhnINPKLwG8nZSqk8i1PNhxU0gkTj7M=; b=kDmxt6Eu6vWTCFSNalZqFqn92IXLBXwr4JOgvsiMwnhiMOhWWP2KoozOIRloX9xnWs CTDnUjFqlf4Ivtdj8MQW8nuIWZlBikkn/C8l/sBTbQfcdRc7Wu5xgZGgO93cyHPKiPGD i1BKVM7simXOMD9AOtbxHPaai5K3DjmNsu5Gm2tSkukFdlRlVkVDIWaBaiYU1rC1i9A/ n/3vfqRArl7J/Sc68hD7IVUJjqtmVwil0uuA4igw3cVBv1W4cHo214KnXsiHMK/jLoYw thlcu/X1zK+QLIVvSq+Su0XN/b/TLVuhvrt/bQgA1f0NrSZbVeLAru2uFw1hgbnks20+ hZ9A==
X-Gm-Message-State: AOAM531SJTtbl/mC/T0n9roovYY7aNVLnkmdIriQpgxCle2+YO+GxMXy jl3jkYgg50lmBfDO7UqhUyC0gw==
X-Google-Smtp-Source: ABdhPJwpvNB/MGaEw5n5QStNwQ9a6r14g5zVHM8RPzw8zlVmihgg5D8CBZd68Ozp+gUcvixbDN17iw==
X-Received: by 2002:a1c:2302:: with SMTP id j2mr5140658wmj.18.1589991407246; Wed, 20 May 2020 09:16:47 -0700 (PDT)
Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id g140sm3205259wmg.47.2020.05.20.09.16.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2020 09:16:46 -0700 (PDT)
From: Joseph Heenan 
Message-Id: <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 20 May 2020 17:16:44 +0100
In-Reply-To: <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com>
Cc: Dave Tonge , oauth , Openid-specs-fapi 
To: Vladimir Dzhuvinov 
References:  <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 May 2020 16:16:52 -0000

--Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks for your thoughts Vladimir!

The client_id based solution I wasn=E2=80=99t previously aware of - =
unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile OS selects the app to use based purely on the URL (and in at =
least the iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).

I think some kind of mapping like you suggest will work and fallback, I =
wonder about a structure in the authorization server metadata something =
like this:

{
  ...
  "alternative_authorization_endpoints": [
    {
      "authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
    },
    {
      "authorization_endpoint": "https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
    }
  ]
}

And as you say, the existing authorization_endpoint can be a fallback =
for clients that are unaware of the new spec or prefer the simpler =
option of just using a single authorization endpoint. Supporting the new =
spec would allow a better UX though so there=E2=80=99s advantages to =
client to do so.
> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be =
sensibly combined with the proposed multi-brand spec.
>=20

I think that particular part is not really an issue as mtls isn=E2=80=99t =
used at the authorization endpoint.

Thanks

Joseph


> On 20 May 2020, at 16:07, Vladimir Dzhuvinov  =
wrote:
>=20
> Hi Dave,
>=20
> In the absence of such a "multi-brand" spec we have tackled this issue =
in the past by letting the "brand" be encoded in the client_id. An =
alternative scenario is to do a "brand" lookup by client_id. Then let =
the AS render the "branded" authZ endpoint.
>=20
> You're probably aware the mTLS spec is allowing for endpoint aliases, =
so this is not the first time such as need has occurred:
>=20
> https://tools.ietf.org/html/rfc8705#section-5 =

> One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".
>=20
> Clients that are aware of the new spec will look it up, those that are =
not will fall back to the std "authorization_endpoint".
>=20
> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be =
sensibly combined with the proposed multi-brand spec.
>=20
>=20
>=20
> Vladimir
>=20
>=20
>=20
> On 20/05/2020 15:07, Dave Tonge wrote:
>> Dear OAuth WG
>>=20
>> We have an issue =
 in the OpenID FAPI Working Group that we believe affects the =
wider OAuth community.
>>=20
>> In summary: what is the recommended approach to discovery (RFC8414) =
for Authorization Servers who support multiple "brands" .
>>=20
>> If brands are completely separate, then it seems sensible that each =
brand must have its own `issuer` and therefore its own discovery =
document at the correct location (i.e. brand 1 would have an issuer of =
"https://as/brand1 " and a discovery document =
available at  https://as/.well-known/ =
oauth-authorization-server/brand1).
>>=20
>> However in the real world it is not always so simple. We have many =
existing implementations in UK open banking that support multiple =
authorization endpoints. Here is an example (thanks to @Joseph Heenan =
 )
>>=20
>> > Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet =
banking, one =E2=80=9Clogin page=E2=80=9D for both business and personal =
customers.
>>=20
>> > They have separate mobile apps for business/personal, and are =
required to support app2app. This means they will definitely be exposing =
multiple authorization endpoints (as there=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.
>>=20
>> > Their choices are:
>>=20
>> > 1. Multiple discovery endpoints (one for business, one for =
personal), each with a different authorization endpoint, multiple =
issuers (if their vendor allows this)
>> > 2. Single discovery endpoint, single issuer, multiple authorization =
endpoints listed in one discovery doc (one for business, one for =
personal) some of which are hardcoded by the 3rd party
>> > 3. Multiple discovery endpoints each with a different authorization =
endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)
>>=20
>> Option 3 is invalid and that leaves us with options 1 and 2.=20
>> Option 1 can be problematic as often it is in reality the same =
`issuer` behind the scenes.
>>=20
>> We would like to get feedback on this issue and potentially an =
extension to RFC8414 to allow the definition of multiple authorization =
endpoints.
>>=20
>> Thanks in advance
>>=20
>> Dave Tonge
>> Co-Chair FAPI WG
>> Open ID Foundation
>>=20
>>=20
>=20


--Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks for your thoughts Vladimir!

The client_id based solution I wasn=E2=80=
=99t previously aware of - unfortunately it doesn=E2=80=99t solve the =
problem for app2app, as the mobile OS selects the app to use based =
purely on the URL (and in at least the iOS case will not offer the user =
a choice if multiple apps claim to handle the same url).

I think some kind of =
mapping like you suggest will work and fallback, I wonder about a =
structure in the authorization server metadata something like =
this:

{
  ...
  =
"alternative_authorization_endpoints": [
  =
  {
      =
"authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business =
banking customers",
      =
"logo_url": "https://loadsamoney/business/logo.png"
    },
    =
{
      "authorization_endpoint": =
"https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal =
customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
    }
  ]
}

And as you say, the existing authorization_endpoint can be a =
fallback for clients that are unaware of the new spec or prefer the =
simpler option of just using a single authorization endpoint. Supporting =
the new spec would allow a better UX though so there=E2=80=99s =
advantages to client to do so.
Speaking of mTLS, =
I'm not sure how the "mtls_endpoint_aliases" can be sensibly combined =
with the proposed multi-brand spec.
I think that particular part is =
not really an issue as mtls isn=E2=80=99t used at the authorization =
endpoint.
Thanks

Joseph


On 20 May 2020, at 16:07, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  
Hi Dave,
In the absence =
of such a "multi-brand" spec we have tackled this
      issue in the past by letting the "brand" be encoded in the
      client_id. An alternative scenario is to do a "brand" lookup by
      client_id. Then let the AS render the "branded" authZ =
endpoint.
You're probably aware the mTLS spec is =
allowing for endpoint
      aliases, so this is not the first time such as need has =
occurred:
https://tools.ietf.=
org/html/rfc8705#section-5
One could devise a =
similar JSON object with mappings "label" -
      "authorization_endpoint".
Clients that are aware =
of the new spec will look it up, those
      that are not will fall back to the std =
"authorization_endpoint".
Speaking of mTLS, I'm not =
sure how the "mtls_endpoint_aliases"
      can be sensibly combined with the proposed multi-brand spec.


    
Vladimir

    


    

    
On 20/05/2020 15:07, Dave Tonge =
wrote:

    

    

      
      

        
Dear OAuth WG

        


        

        
We have an issue in the =
OpenID FAPI Working
          Group that we believe affects the wider OAuth community.

        


        

        
In summary: what is the =
recommended
            approach to discovery (RFC8414) for Authorization
            Servers who support multiple "brands" .

        


        

        
If brands are completely separate, then it
          seems sensible that each brand must have its own `issuer` and
          therefore its own discovery document at the correct location
          (i.e. brand 1 would have an issuer of "https://as/brand1"
          and a discovery document available at  https://as/.well-known/oauth-authorization-server/brand1).

        


          

        
However
            in the real world it is not always so simple. We have many
            existing implementations in UK open banking that
            support multiple authorization endpoints. Here is an =
example
            (thanks to @Joseph =
Heenan )

        


          

        
> Bank =E2=80=9Cloadsamoney=E2=80=9D has one =
idp and, for
          internet banking, one =E2=80=9Clogin page=E2=80=9D for both =
business and
          personal customers.

          

          > They have separate mobile apps for business/personal, and
          are required to support app2app. This means they will
          definitely be exposing multiple authorization endpoints (as
          there=E2=80=99s a 1:1 mapping of authorization endpoints to =
mobile
          apps) - the choice is how they do this.

          

          > Their choices are:

          

          > 1. Multiple discovery endpoints (one for business, one
          for personal), each with a different authorization endpoint,
          multiple issuers (if their vendor allows this)

          > 2. Single discovery endpoint, single issuer, multiple
          authorization endpoints listed in one discovery doc (one for
          business, one for personal) some of which are hardcoded by the
          3rd party

          > 3. Multiple discovery endpoints each with a different
          authorization endpoint, same issuer in all cases (breaks
          RFC8414 and OIDC Discovery)

        

        


        

        

          
Option 3 is invalid and that leaves us
            with options 1 and 2. 

          
Option 1 can be problematic as often it
            is in reality the same `issuer` behind the scenes.

          


          

          
We would like to get feedback on this
            issue and potentially an extension to RFC8414 to allow the
            definition of multiple authorization endpoints.

          


          

          
Thanks in advance

          


          

          
Dave Tonge

          
Co-Chair FAPI WG

          
Open ID Foundation

          


          

        

        


        

      

    

    

  




=

--Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414--


From nobody Wed May 20 15:48:41 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234D33A0896 for ; Wed, 20 May 2020 15:48:39 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx38byCpGLCJ for ; Wed, 20 May 2020 15:48:34 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796653A088C for ; Wed, 20 May 2020 15:48:34 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id f3so5248307ioj.1 for ; Wed, 20 May 2020 15:48:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KKJFxMrFvJaMFRjLn1wxWQLV7Tur58hRPE46tt3iv0A=; b=EJNw2Z3nU/D+2Wanw4XB23IMHC0EH/GGm3W6Zj67N370nNF5NB7lpUCg0YnSMvM8jH QMR/kF0i1Jo4Sva1tBV5UhNDTrDUoPD16OoZC1UCZ7F5zx7XGigMMgPZXcWddC7xg+Y0 UzuhrPlPM1V3nsd+UON5wnnnLXJ7qjbh6qsxkAqJG9iq41ZAeP+WGDLRjVIg/+m+9OY8 tmfRCnqrDooMxXSfS6w9D/9Yk3PtXFPfBHVo9tiy6gGfRBl27isLtfNLnjUURhs+wS/R 8Pz4GBOIqHDFi1h0Ps4hOPNBlBINQOz7bVIxo2C9/dnZm5QmAWy55GUXhiIO5KfqxTRO 8PjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKJFxMrFvJaMFRjLn1wxWQLV7Tur58hRPE46tt3iv0A=; b=YRJvv9SdtGuZMB2XanTlOsGUZkEiTohN8DcGuO5qpvt2wDOYhCRBXrtbqQSX/Jz00j zXZtOhzIJclb1fR7um/pwI5EEUu2HpIQMMpo57tAYm7P+5zq7to9RG+q6yv95GgUYia5 tCEQ4/PRSwU1MDzuw7i+3bEe9C2Gcu8erB//RezuYG6PfY6qun8zrCAhOI1ZuR3d5xTu 1INkz7WDpHUoRtBR44VpiCvYFzvIY33NNSYGBdx6cbA2cBP80qZHDP6YnlTk+tKdkxuk 2KqQml+/Jzwtq7+cvjBQmpTabIP8pwccejaZMlFHhfwsDboFJeFlnr0g2IjqVDKyI/B/ Gy1Q==
X-Gm-Message-State: AOAM530vaMTtkzfEKUTaZpNK7UGvbzsXmMmOkJ2QhbvPladh1+HTje7Z ZHNxK8rkdaG63l+FG1BQGkJyFq0NJe4=
X-Google-Smtp-Source: ABdhPJxB6s9IFEO+tez7O3WR0EzgzAVNxq6+5uBZipdTBE0L23L6SpTkPnZn2rDiKfnBF5+MGJ2fmQ==
X-Received: by 2002:a6b:14c9:: with SMTP id 192mr2924412iou.174.1590014912795;  Wed, 20 May 2020 15:48:32 -0700 (PDT)
Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id u2sm1645583ion.50.2020.05.20.15.48.31 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 15:48:31 -0700 (PDT)
Received: by mail-io1-f49.google.com with SMTP id j8so5152662iog.13 for ; Wed, 20 May 2020 15:48:31 -0700 (PDT)
X-Received: by 2002:a6b:d219:: with SMTP id q25mr5415759iob.202.1590014911186;  Wed, 20 May 2020 15:48:31 -0700 (PDT)
MIME-Version: 1.0
References:  <67F643A9-47E5-4339-B6B0-E39C7B959EF7@gmail.com>
In-Reply-To: <67F643A9-47E5-4339-B6B0-E39C7B959EF7@gmail.com>
From: Aaron Parecki 
Date: Wed, 20 May 2020 15:48:20 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Nov Matake 
Cc: Mike Jones , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000f80ca305a61c3129"
Archived-At: 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 May 2020 22:48:40 -0000

--000000000000f80ca305a61c3129
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

So if I'm understanding this correctly, it sounds like the AS needs to
reject a token request with code_verifier if the authorization code was
issued in response to a request that did not contain a code_challenge. This
to me sounds like it would be simpler to just say the code_challenge and
code_verifier are always required.

That said, I do understand the previously discussed concerns around
existing OpenID Connect clients.

I believe the text that Daniel proposed is the best of both worlds, and I
support making this change in both OAuth 2.1 and the Security BCP.

Aaron Parecki



On Tue, May 19, 2020 at 9:29 AM Nov Matake  wrote:

> Yes.
>
> The root problem isn=E2=80=99t the mix-use of PKCE and nonce, it=E2=80=99=
s PKCE
> implementation bug.
> Yeah, all PKCE implementation MUST reject such requests, regardless it=E2=
=80=99s
> OAuth 2.1 or 2.0.
>
> (and it=E2=80=99s probably because of PKCE spec=E2=80=99s ambiguity..)
>
> 2020/05/20 1:13=E3=80=81Mike Jones =E3=81=AE=
=E3=83=A1=E3=83=BC=E3=83=AB:
>
> So it sounds me like the fix is to have servers reject PKCE requests with
> incomplete parameter sets: requests that only contains one of
> code_challenge and code_verified.  Will that eliminate the attack, Nov?
>
>                                                        -- Mike
>
> *From:* OAuth  *On Behalf Of *Nov Matake
> *Sent:* Monday, May 18, 2020 11:50 PM
> *To:* Daniel Fett 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
> Sure, feel free to add the senario to your post.
>
> FYI:
> my OAuth2 server ruby gem rejects such token requests,
>
> https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/ext=
ension/pkce.rb#L28
> and Google also does the same.
> https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046
>
> So I'm guessing such behavior is relatively rare-case, hopefully.
>
> iPad=E3=81=8B=E3=82=89=E9=80=81=E4=BF=A1
>
>
> 2020/05/19 15:43=E3=80=81Daniel Fett =E3=81=AE=E3=83=
=A1=E3=83=BC=E3=83=AB:
>
> =EF=BB=BF
> Hi,
>
> Am 19.05.20 um 04:55 schrieb Nov Matake:
>
> I thought the server MUST reject such token requests, but I couldn=E2=80=
=99t find
> such definition in RFC7636...
>
> > The client will send the code, along with a (now not matching)
> code_verifier to the server. The server will ignore the code_verifier (as
> it was not expected) and send back an access token and ID token to the
> client.
>
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepk=
ce-sidestep-attack
>
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2=
=80=9D
> would be possible.
>
> I *think* that there is nothing preventing servers from sometimes using
> PKCE and sometimes using Nonce. I assume that this is out of the scope of
> the existing specifications.
>
> I would be interested to hear how actual implementations handle this in
> practice.
>
>
> Plus, with such AS behavior, CSRF protection using PKCE can also be
> bypassed as below.
> 1. The attacker removes code_challenge from his/her own AuthZ
> Req, receives a non-code_challenge-bound code, and sends it to the victim=
.
> 2. The client receives the attacker=E2=80=99s code from the victim, and s=
ends it
> to the AS w/ the valid code_verifier bound to the victim=E2=80=99s browse=
r session.
> 3. The AS ignores the code_verifier and returns tokens.
>
> If that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can be =
weaker
> than expected..
>
> Excellent point!
>
> Would it be okay if I add that attack to the original post (with credits,
> of course)?
>
> -Daniel
>
>
> nov
>
>
> 2020/05/19 1:54=E3=80=81Daniel Fett =E3=81=AE=E3=83=
=A1=E3=83=BC=E3=83=AB:
>
> Hi all,
>
> Talking to Torsten, we realized that providing a generic extension point
> here is probably not a good idea. It is really hard to tell what protects
> you from code injection and what does not, and people might come up with
> all sorts of non-standard and potentially insecure solutions.
>
> Even just for PKCE vs. Nonce, it is not obvious if they provide the same
> level of protection. In an attempt to answer this question, I tried to co=
me
> up with a more systematic analysis of "PKCE vs Nonce". I wrote up my
> results here:
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>
> Although this is not a formal analysis, I hope that I have covered all
> interesting cases. Please review the text and let me know if I have misse=
d
> something or if there are any mistakes.
>
> The main results are:
>
>    1. In terms of protection against CSRF and code misuse, PKCE and Nonce
>    provide similar levels of security, with a slight advantage for PKCE.
>    2. In practice, a circumvention of both mechanisms, however, is
>    possible if an AS allows a client to choose between PKCE and Nonce and=
 the
>    client makes use of this freedom. I propose to call this attack the
>    Nonce/PKCE Sidestep Attack. =E2=86=92 Please review the attack descrip=
tion in the
>    analysis.
>    3. To avoid the Nonce/PKCE Sidestep Attack, clients must not switch
>    between using only PKCE and only Nonce (but may use both in parallel, =
or
>    switch between using only PKCE and PKCE+Nonce). Authorization servers =
must
>    enforce PKCE unless they know that the client uses Nonce for all of it=
s
>    flows (and checks the Nonce value). The presence of a nonce parameter =
in
>    the authorization request is not sufficient to determine if a client
>    actually checks the nonce claim in the ID token.
>
> As you can see, already having two more-or-less well-understood mechanism=
s
> is hard enough to wrap your head around from a security standpoint. We
> should therefore make PKCE the default and Nonce an option for backwards
> compatibility.
> To this end, I would like to propose the follwing strawman, based on
> Torsten's and Aaron's suggestions:
> An AS MUST reject requests without a code_challenge from public
> clients, and MUST reject such requests from other clients unless there
> is reasonable assurance that the client mitigates authorization code
> injection using the OpenID Connect Nonce mechanism and that this
> mitigation is used for all interactions with the client. See section
> 9.7 for details.
>
> Section 9.7:
>
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. The use of the
> `code_challenge` parameter is RECOMMENDED to this end. For
> confidential clients, the OpenID Connect `nonce` parameter and ID
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
> `code_challenge` parameter for this purpose. The `code_challenge` or
> OpenID Connect `nonce` value MUST be transaction-specific and securely
> bound to the client and the user agent in which the transaction was
> started.
>
> If the OpenID Connect `nonce` is used to mitigate authorization code
> injection instead of `code_challenge`, client and authorization server
> MUST ensure that the mitigation is applied to every interaction with
> the client and that the client cannot switch between `code_challenge`
> and `nonce`. For example, the presence of a `nonce` parameter in the
> authorization request is not sufficient to determine that the
> `code_verifier` check can be skipped.
>
> Of course, we need to adapt the wording in the Security BCP accordingly.
> -Daniel
>
>
> Am 15.05.20 um 01:01 schrieb Mike Jones:
>
> I agree with Nov that obscuring the language in 9.7 would be a disservice=
 to developers.
>
>
>
> The Security BCP, which has already going the WGLC, explicitly calls out =
the use of nonce as part of the best practices.  OAuth 2.1 should do no les=
s.
>
>
>
> The 9.7 language that Aaron proposed was the result of many people's cont=
ributions and a vigorous discussion.  Let's publish the next version of 2.1=
 with that language intact, as I believe it represents at least a local poi=
nt of hard-won consensus.  Let's get that language into the record of draft=
s.
>
>
>
> There's always time to debate it and change it later in subsequent drafts=
, but let's not now lose what it took a lot of effort to achieve.
>
>
>
>     Thanks,
>
>     -- Mike
>
>
>
> -----Original Message-----
>
> From: Nov Matake  
>
> Sent: Thursday, May 14, 2020 3:18 AM
>
> To: Torsten Lodderstedt  
>
> Cc: OAuth WG  ; Mike Jones  
>
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
>
>
> There is no specific mechanism right now.
>
> But future developers won=E2=80=99t be able to read the reason why the ex=
tension point is given only for confidential clients.
>
>
>
> On May 14, 2020, at 18:32, Torsten Lodderstedt  =
 wrote:
>
>
>
> Are you aware of any suitable mechanism? I=E2=80=99m asking since from my=
 perspective this clause is mainly intended to allow existing OpenID Connec=
t deployments to use nonce instead of PKCE in combination with OAuth 2.1. I=
t=E2=80=99s a compromise. I think we should not encourage others to invent =
their own OAuth security mechanisms.
>
>
>
> On 14. May 2020, at 09:37, Nov Matake   wrote:
>
>
>
> Hi,
>
>
>
> Why not allowing public clients use "other suitable mechanisms=E2=80=9D t=
hen?
>
> OAuth WG can allow both type of clients do so, then OIDF will define nonc=
e as the alternative only for confidential clients.
>
>
>
> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt  =E3=81=AE=E3=
=83=A1=E3=83=BC=E3=83=AB:
>
>
>
> Hi all,
>
>
>
> I would also like to thank everybody for the substantial discussion.
>
>
>
> The proposed change for Section 4.1.2.1 works for me (as already stated).=
 I=E2=80=99m not fully comfortable with the proposed change for Section 9.7=
 for the following reasons:
>
>
>
> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE=
 instead of requiring it (with a well-defined exception).
>
> - Given the latest findings re nonce I don=E2=80=99t feel comfortable wit=
h recommending any mechanism that this WG is not responsible for and thus d=
id not conduct the security threat analysis for. I think the better way for=
 us as WG is to define the extension point for other mechanisms. The OpenID=
 Foundation (or any other body) can then fill in and issue a statement that=
 nonce (or another suitable mechanism) fulfils the requirements of the exte=
nsion point.
>
>
>
> Based on this considerations, I propose the following text for Section 9.=
7:
>
>
>
> Clients MUST prevent injection (replay) of authorization codes into
>
> the authorization response by attackers. Public clients MUST use the
>
> "code_challenge=E2=80=9D with a transaction-specific value that is secure=
ly
>
> bound to the client and the user agent in which the transaction was
>
> started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=
=9D in the
>
> same way or other suitable mechanisms to mitigate authorization code
>
> injection.
>
>
>
> This text follows the logic in Section 4.1.2.1 and allows use of the nonc=
e for confidential clients.
>
>
>
> best regards,
>
> Torsten.
>
>
>
> On 12. May 2020, at 02:21, Mike Jones   wrote:
>
>
>
> That works for me.  Thanks all for the useful back-and-forth that got us =
to this point of clarity.  I suspect many of us learned things along the wa=
y; I know that I did!
>
>
>
>                                                     Cheers,
>
>                                                     -- Mike
>
>
>
> From: Aaron Parecki  
>
> Sent: Monday, May 11, 2020 4:55 PM
>
> To: OAuth WG  
>
> Cc: Neil Madden  ; =
Mike Jones
>
>  
>
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
>
>
> Thank you Neil.
>
>
>
> To address Mike's concerns in the previous threads, I would like to also =
update section 9.7 with the following text:
>
>
>
> Clients MUST prevent injection (replay) of authorization codes into
>
> the authorization response by attackers. The use of the
>
> `code_challenge` parameter is RECOMMENDED to this end. For
>
> confidential clients, the OpenID Connect `nonce` parameter and ID
>
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
>
> `code_challenge` parameter for this purpose. The `code_challenge`
>
> or OpenID Connect `nonce` value MUST be transaction-specific and
>
> securely bound to the client and the user agent in which the transaction =
was started.
>
>
>
> This change better clarifies the specific circumstances under which the "=
nonce" parameter is sufficient to protect against authorization code inject=
ion.
>
>
>
> Aaron Parecki
>
>
>
> On Mon, May 11, 2020 at 11:55 AM Neil Madden  =
 wrote:
>
> I am happy with this proposed wording. Thanks for updating it.
>
>
>
> =E2=80=94 Neil
>
>
>
>
>
> On 11 May 2020, at 19:52, Aaron Parecki   wrote:
>
>
>
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
>
>
>
> We would like to propose the following text, which is a slight variation =
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (h=
ttps://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) tha=
t begins with "If the client does not send the "code_challenge" in the requ=
est..."
>
>
>
> "An AS MUST reject requests without a code_challenge from public clients,=
 and MUST reject such requests from other clients unless there is reasonabl=
e assurance that the client mitigates authorization code injection in other=
 ways.. See section 9.7 for details."
>
>
>
> Section 9.7 is where the nuances of PKCE vs nonce are described.
>
>
>
> As Neil described, we believe this will allow ASs to support both OAuth 2=
.0 and 2.1 clients simultaneously. The change from Neil's text is the clari=
fication of which threats, and changing to MUST instead of SHOULD. The "MUS=
T...unless" is more specific than "SHOULD", and since we are already descri=
bing the explicit exception to the rule, it's more clear as a MUST here.
>
>
>
> Aaron Parecki
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000f80ca305a61c3129
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


So if I'm understanding this correctly, it sounds like=
 the AS needs to reject a token request with code_verifier if the authoriza=
tion code was issued in response to a request that did not contain a code_c=
hallenge. This to me sounds like it would be simpler to just say the code_c=
hallenge and code_verifier are always required.

That sai=
d, I do understand the previously discussed concerns around existing OpenID=
 Connect clients.

I believe the text that Daniel p=
roposed is the best of both worlds, and I support making this change in bot=
h OAuth 2.1 and the Security BCP.

Aaron Parecki



<=
div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 19, 2020 at 9:29 AM Nov Ma=
take <matake@gmail.com> wrote=
:
Yes.

The root problem isn=E2=80=99=
t the mix-use of PKCE and nonce, it=E2=80=99s PKCE implementation bug.
Yeah, all PKCE implementation MUST r=
eject such requests, regardless it=E2=80=99s OAuth 2.1 or 2.0.
=


(and it=E2=80=99s=C2=A0probably=C2=A0because of =
PKCE spec=E2=80=99s ambiguity..)

2020/05/20 1:13=E3=80=81Mike Jones <Michael.Jones@microsoft.com=
>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

So it sounds me like the fix=
 is to have servers reject PKCE requests with incomplete parameter sets: re=
quests that only contains one of code_challenge and code_verified.=C2=A0 Wi=
ll that eliminate the attack, Nov?
=C2=A0
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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:=C2=A0OAuth <oauth-bounces@ietf.org>=C2=A0On Behalf Of=
=C2=A0Nov Matake
Sent:=C2=A0Monday, May 1=
8, 2020 11:50 PM
To:=C2=A0Daniel Fett <fett@danielfett.de>
Cc:=C2=A0oauth@ietf.org
Subject:=C2=A0=
Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
=C2=A0
Sure=
, feel free to add the senario to your post.
=

=C2=A0
FYI:
my OAuth2 server ruby gem rejects such token requests,=

=C2=A0
Am 19.05.20 um 04:55 schrieb Nov Matake:
=

I thought the server MUST reject such token requests, but I could=
n=E2=80=99t find such definition in RFC7636...
=C2=A0
>=C2=A0Th=
e client will send the code, along with a (now not matching) code_verifier =
to the server. The server will ignore the code_verifier (as it was not expe=
cted) and send back an access token and ID token to the client.
=C2=A0
If the behavior is acceptable by RFC7636, "Nonce/PKCE Sides=
tep Attack=E2=80=9D would be possible.
I *think* that there is nothing preventing servers f=
rom sometimes using PKCE and sometimes using Nonce. I assume that this is o=
ut of the scope of the existing specifications.
I would=
 be interested to hear how actual implementations handle this in practice.<=
u>
=C2=A0
Plus, =
with such AS behavior, CSRF protection using PKCE can also be bypassed as b=
elow.
1. The attacker removes code_=
challenge from his/her own AuthZ Req,=C2=A0receives=C2=A0a non-code_challen=
ge-bound code, and sends it to the victim.
2. The client receives the attacker=E2=80=99s code from the victim,=
 and sends it to the AS w/ the valid code_verifier bound to the victim=E2=
=80=99s browser session.
3. The AS =
ignores the code_verifier and returns tokens.
=C2=A0
If that=E2=80=99s=
 the case, current OAuth 2.0 PKCE implementation can be weaker than expecte=
d..
Excellent point!
Would it be okay if I add that attack to the original po=
st (with credits, of course)?
-Daniel
=

=C2=A0
nov
=



2020/05/19 1:54=E3=80=81Daniel Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
=C2=A0
Hi all,
=C2=A0<=
/div>
Talking to Torsten, we realized that providing a =
generic extension point here is probably not a good idea. It is really hard=
 to tell what protects you from code injection and what does not, and peopl=
e might come up with all sorts of non-standard and potentially insecure sol=
utions.=C2=A0
=
=C2=A0
Even just for PKCE vs. Nonce, it is=
 not obvious if they provide the same level of protection. In an attempt to=
 answer this question, I tried to come up with a more systematic analysis o=
f "PKCE vs Nonce". I wrote up my results here:

Although this is not a for=
mal analysis, I hope that I have covered all interesting cases. Please revi=
ew the text and let me know if I have missed something or if there are any =
mistakes.

The main results are:
  1. In terms=
 of protection against CSRF and code misuse, PKCE and Nonce provide similar=
 levels of security, with a slight advantage for PKCE.
    2. In practice, a circumvention of both mechanisms,=
 however, is possible if an AS allows a client to choose between PKCE and N=
once and the client makes use of this freedom. I propose to call this attac=
k the Nonce/PKCE Sidestep Attack. =E2=86=92 Please review the attack descri=
ption in the analysis.
  2. To av=
oid the Nonce/PKCE Sidestep Attack, clients must not switch between using o=
nly PKCE and only Nonce (but may use both in parallel, or switch between us=
ing only PKCE and PKCE+Nonce). Authorization servers must enforce PKCE unle=
ss they know that the client uses Nonce for all of its flows (and checks th=
e Nonce value). The presence of a nonce parameter in the authorization requ=
est is not sufficient to determine if a client actually checks the nonce cl=
aim in the ID token.
As you can see, alrea=
dy having two more-or-less well-understood mechanisms is hard enough to wra=
p your head around from a security standpoint. We should therefore make PKC=
E the default and Nonce an option for backwards compatibility.
To this end, I would like to propose the follwing strawman=
, based on Torsten's and Aaron's suggestions:
An AS MUST reject requests without a code_challenge from publ=
ic
clients, and MU=
ST reject such requests from other clients unless there
is reasonable assurance that the c=
lient mitigates authorization code
injection using the OpenID Connect Nonce mechanism and th=
at this
mitigatio=
n is used for all interactions with the client. See section
9.7 for details.
=

Section 9.7:

<=
span style=3D"font-size:10pt">Clients MUST prevent injection (replay) of au=
thorization codes into
the authorization response by attackers. The use of the
`code_challenge` parameter is R=
ECOMMENDED to this end. For
confidential clients, the OpenID Connect `nonce` parameter and I=
D
Token Claim {{O=
penID}} MAY be used instead of or in addition to the
`code_challenge` parameter for this pur=
pose. The `code_challenge` or
OpenID Connect `nonce` value MUST be transaction-specific and =
securely
bound to=
 the client and the user agent in which the transaction was
started.

If the OpenID Connect `nonce` is u=
sed to mitigate authorization code
injection instead of `code_challenge`, client and authori=
zation server
MUS=
T ensure that the mitigation is applied to every interaction with
<=
tt style=3D"font-family:"Courier New"">the client and that the cl=
ient cannot switch between `code_challenge`
and `nonce`. For example, the presence of a `non=
ce` parameter in the
authorization request is not sufficient to determine that the
<=
tt style=3D"font-family:"Courier New"">`code_verifier` check can =
be skipped.
=C2=A0
Of course, we need to adapt the wording in the Security BCP a=
ccordingly.
-Daniel
=C2=A0
=C2=A0
Am 15.05.20 um 01:01 schrieb Mike Jones:
=C2=A0
The Security BCP, which has already going the WGLC, explici=
tly calls out the use of nonce as part of the best practices.=C2=A0 OAuth 2=
.1 should do no less.
=C2=A0
The 9.7 language that Aaron proposed was the result o=
f many people's contributions and a vigorous discussion.=C2=A0 Let'=
s publish the next version of 2.1 with that language intact, as I believe i=
t represents at least a local point of hard-won consensus.=C2=A0 Let's =
get that language into the record of drafts.
=C2=A0
There's always time to de=
bate it and change it later in subsequent drafts, but let's not now los=
e what it took a lot of effort to achieve.
    Thanks,
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">    -- Mike
=C2=A0
-----Original Message-----
From: Nov Matake <matake@gmail.com=
> 
Sent: Thursday, May 14, 2020 3:=
18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@ietf.org>=
;; Mike Jones <Michael.Jones@mi=
crosoft.com>
Subject: Re: [OAUTH-W=
G] proposed resolution for PKCE in OAuth 2.1
=C2=A0
There is no specific mechanis=
m right now.
But future developers won=E2=
=80=99t be able to read the reason why the extension point is given only fo=
r confidential clients.
=C2=A0<=
/u>
On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">=C2=A0
Are you aware of any=
 suitable mechanism? I=E2=80=99m asking since from my perspective this clau=
se is mainly intended to allow existing OpenID Connect deployments to use n=
once instead of PKCE in combination with OAuth 2.1. It=E2=80=99s a compromi=
se. I think we should not encourage others to invent their own OAuth securi=
ty mechanisms. 
=C2=A0
On 1=
4. May 2020, at 09:37, Nov Matake <matake@gmai=
l.com> wrote:
=C2=A0=

Hi,
=C2=A0=

Why not allowing public clients use "other su=
itable mechanisms=E2=80=9D then?
OAuth WG=
 can allow both type of clients do so, then OIDF will define nonce as the a=
lternative only for confidential clients.
=C2=A0
2020/05/14 15:56=E3=80=81Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org&g=
t;=E3=81=AE=E3=83=A1=
=E3=83=BC=E3=83=AB:
=C2=A0<=
u>
Hi all,
=C2=A0
I would also like to thank everybody for=
 the substantial discussion.=C2=A0 
=C2=A0
The proposed change for Section 4.1.2.1=
 works for me (as already stated). I=E2=80=99m not fully comfortable with t=
he proposed change for Section 9.7 for the following reasons:=

=C2=A0
- The text is=
 weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE instead of req=
uiring it (with a well-defined exception).
=C2=A0
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">Based on this considerations, I propose the following text fo=
r Section 9.7:
=C2=A0
=

Clients MUST prevent injection (replay) of authorization cod=
es into 
the authorization response by at=
tackers. Public clients MUST use the 
&qu=
ot;code_challenge=E2=80=9D with a transaction-specific value that is secure=
ly 
bound to the client and the user agen=
t in which the transaction was 
started. =
Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=9D in the <=
u>
same way or other suitable mechanisms to =
mitigate authorization code 
injection.
=C2=A0
T=
his text follows the logic in Section 4.1.2.1 and allows use of the nonce f=
or confidential clients.
=C2=A0=

best regards,
To=
rsten. 
=C2=A0
On 12. May 2=
020, at 02:21, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:=

=C2=A0
Th=
at works for me.=C2=A0 Thanks all for the useful back-and-forth that got us=
 to this point of clarity.=C2=A0 I suspect many of us learned things along =
the way; I know that I did!
=C2=A0=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 -- Mike
=C2=A0=

From: Aaron Parecki <aar=
on@parecki.com>
Sent: Monday, May =
11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
C=
c: Neil Madden <neil.madden@forgerock=
.com>; Mike Jones 
<Michael.Jones@microsoft.com>=

Subject: Re: [OAUTH-WG] proposed resolution for PKCE i=
n OAuth 2.1
=C2=A0
Thank you Neil.
=C2=A0=

To address Mike's concerns in the previous =
threads, I would like to also update section 9.7 with the following text:
=C2=A0
C=
lients MUST prevent injection (replay) of authorization codes into <=
u>
the authorization response by attackers. The use=
 of the 
`code_challenge` parameter is RE=
COMMENDED to this end. For 
confidential =
clients, the OpenID Connect `nonce` parameter and ID 
Token Claim {{OpenID}} MAY be used instead of or in addition t=
o the 
`code_challenge` parameter for thi=
s purpose. The `code_challenge` 
or OpenI=
D Connect `nonce` value MUST be transaction-specific and 
securely bound to the client and the user agent in which t=
he transaction was started.
=C2=A0=

This change better clarifies the specific circu=
mstances under which the "nonce" parameter is sufficient to prote=
ct against authorization code injection.
=
=C2=A0
Aaron Parecki
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">=C2=A0
On Mon, May 11, 2020=
 at 11:55 AM Neil Madden <neil.madden=
@forgerock.com> wrote:
I am happy =
with this proposed wording. Thanks for updating it.
=C2=A0
=E2=80=94 Neil
=C2=A0
=
=C2=A0
On 11 May 2020, at 19:52, Aaron Parecki <=
a href=3D"mailto:aaron@parecki.com" style=3D"color:blue;text-decoration:und=
erline" target=3D"_blank"><aaron@parecki.com> wrote:
=C2=A0
Thanks for t=
he lively discussion around PKCE in OAuth 2.1 everyone! 
=C2=A0
We would like to p=
ropose the following text, which is a slight variation from the text Neil p=
roposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org=
/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins with &qu=
ot;If the client does not send the "code_challenge" in the reques=
t..."
=C2=A0
"An AS MUST reject requests without a code_challenge from p=
ublic clients, and MUST reject such requests from other clients unless ther=
e is reasonable assurance that the client mitigates authorization code inje=
ction in other ways.. See section 9.7 for details."
=C2=A0
Section 9.7 is whe=
re the nuances of PKCE vs nonce are described.
=C2=A0
As Neil described, we believ=
e this will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneou=
sly. The change from Neil's text is the clarification of which threats,=
 and changing to MUST instead of SHOULD. The "MUST...unless" is m=
ore specific than "SHOULD", and since we are already describing t=
he explicit exception to the rule, it's more clear as a MUST here.
=C2=A0
Aaro=
n Parecki
=C2=A0
=C2=A0
=C2=A0
=C2=A0
_________________=
______________________________
OAuth mail=
ing list
OAuth@ie=
tf.org
https://www.ietf.org/mailman/listinfo/oauth
=C2=A0
___________=
____________________________________
OAut=
h mailing list
OA=
uth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_________________________________=
______________
OAuth mailing list<=
u>
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth
_____________________________=
__________________
OAuth mailing list<=
/u>
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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



--000000000000f80ca305a61c3129--


From nobody Wed May 20 16:13:14 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6953A0974 for ; Wed, 20 May 2020 16:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmw0PTb15G-7 for ; Wed, 20 May 2020 16:13:00 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650131.outbound.protection.outlook.com [40.107.65.131]) (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 84D673A08EA for ; Wed, 20 May 2020 16:12:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iK+JMqRVIfPuRyxEwGFbm295ppvdSuGYTR6x1FKPaNslM9Z6wRduaskkkhDHR3bvicad3UpSoczMNUaEFcQKM/wGXE6WnxBbAJjNAgMz4zLDvKA6eeHT7f6Rl7kLQCs5RqkomMspzIHYhJ0oj2V2uacnrs0AKOO486oqLKzBvprK+6uG90R59GsS/1qKYCqAx30XOZ0Mk7GcmtWZq0+V4x4lqA792+4PVmquqsxgBiQ4riX8yjrImShNdyDgxzFqbYtM1EGTcXiTHe3ykQKf1r1ABgTRkRC7Aumvimk1ei35jXCKbhOkBDxcLyRvtCo5OyHhdsu1+QknbwYrgYVBuQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wOnhP+XBjGKHVIcXhvaLAoYJuFS6ViJsTTSjlwlB9NM=; b=LblheDmwJvJe98k74dTee0meKEzNixb31q8s85bK3BTd0vx15SHlhztr6n64o3EFHdrz0kiV7/DoJjeyQUnOLPXfEE0CeMLo2xwg0TzyuipnT5K05eeFsVe6GZV03ijqaP8JKe75VToJaGWPMfPQbV6HoaLwVEaAku0hg6pmOA9yMik7LDXgIWHbugea1eopiqSyD6OitgzzV8WMoJjR9fs/oIjVKWqpKCfsQYDzf9bknIavGB5Yq9AaNIphpyXtsBA3fCAIiDRVmRU6KJh3cV3USfVM4C+weDb0uoIXMDZumosRhbyr6SYndn3XTz7NwxyCmbxjgkup9U/TlvmZ7A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wOnhP+XBjGKHVIcXhvaLAoYJuFS6ViJsTTSjlwlB9NM=; b=c6H+2GRdZZiRDKJnzpuchhZpWd7/sgF1BVrynzT791B/kn/84wYFS0ObcOZilmG7aX3y+O2HubOFb4/bFlEAboA6QNzH+jbhcdlRFKiPmFs6lJzOBzh+tq7kzLVisKkRGZ/H21VTlIqOXcI+CzYTGsmRZRZuSCqAs+erpcGSYUs=
Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM5PR00MB0357.namprd00.prod.outlook.com (2603:10b6:4:9f::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3063.0; Wed, 20 May 2020 23:12:56 +0000
Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::9101:55b5:7415:d38d]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::9101:55b5:7415:d38d%5]) with mapi id 15.20.3064.000; Wed, 20 May 2020 23:12:56 +0000
From: Mike Jones 
To: Aaron Parecki , Nov Matake 
CC: "oauth@ietf.org" 
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
Thread-Index: AdYt+Hgi6C49zluNRV+Y2W1Ic4YJWgAAiZ4AAD+I6gAAAKM2QA==
Date: Wed, 20 May 2020 23:12:56 +0000
Message-ID: 
References:  <67F643A9-47E5-4339-B6B0-E39C7B959EF7@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f7b259e6-e8b7-4cba-a18d-0000206a8f06; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-20T23:06:36Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:8:1237:25f2:370:c3d7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: feae59f8-ed24-4b2e-f8e0-08d7fd13549f
x-ms-traffictypediagnostic: DM5PR00MB0357:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04097B7F7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 40HCNjByArClD9yJ459Wbx4qKRAnUOMo7UJVu4cyAG2Cx94jaMQd5LGgGEbNVe48s1SNVd5+Eq1JlR8sYkhtRIa4MCPzg7FqEEBf/bpDUqZ0geuq5YAibC+oIaKEKMKf4nhbrtDMexLYYj3Eqwh7ByE+x2Z7za7AzFt5Gw59EZcWymgJUkE0Dl6f+M0G/c6zJLGBEiB5f8Mzh3JMai5BetRzSbk5z/myjMDyks7Dep7fvP3NwCwXIpHRB3US5q+mMRxkzamL9dt0/1iyI1ezC0hKkxGgVGr/q88AM5z2JHEFrzLAawr1vnZnXcZqVdTrRLMYcQcBCHFbtoIHRUYzvIIwoL04cCzhGizJwA/YNSOWDhYv79k4uDz51GW0nEMt9lYYD89DyLW8htRzijV8UQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(366004)(136003)(376002)(396003)(39860400002)(8936002)(110136005)(316002)(2906002)(64756008)(66946007)(66446008)(8676002)(55016002)(33656002)(86362001)(7696005)(966005)(52536014)(66476007)(76116006)(66556008)(9686003)(4326008)(478600001)(71200400001)(82950400001)(30864003)(83080400001)(8990500004)(10290500003)(186003)(66574014)(53546011)(6506007)(166002)(82960400001)(5660300002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: Qlf/EwCdpq/ly+1ghHOyOXgDFAKUvSF4qyagGQEJADqnVvj9LxqPcNEWIvH7zYL1uIMoq2iM2U663l9Y2VfJ64jdWWfovvA25YQ5h/JNqro/f4hauRPQvTdZQd0ku0m9JhG2H/tzO4WNxATFzI1RGCUXGbbDtN1NHnT4sT7v3uWH+yI+Qz2uGrVd6Wa5RAy9JqvOR2Tmpig/7acyMzZKHTqHoW+3wSEs5Uv58t90m+hH4VpGStowsDdvxecGLF5+6VU9cVIqktk9LqzL4BiozKbUrvxhCeYZoJuejrUXhZVwY/rrPmNorKxTB/d4OpKCs9aHF7cIRlE7m4KburF48YzgnlbJm0JIv9RnTjeO5CR3iMFoLjfNZwuFkxreRIAzUftxouHAyOSAfTPyr3rR134iyhyRHbFQTeTgbpAJIHfPxoL9LMfwZGSz+eozbUYDIYO81T1AOoon3VuZJPypMKjODFyKD+dT+K4fCPncxno0vYmnbBvwbDrGoaXZQZHGYo9qmUoWHXTLP29dcjMHrA/AVbPW5vj+PEMJ6Q1Jiko=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0684E59FE5A75B15E1C432C6F5B60DM6PR00MB0684namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: feae59f8-ed24-4b2e-f8e0-08d7fd13549f
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 23:12:56.1752 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MpF9GDl5+Vm0cT8RlIKXG15CBr+XAvBJ1xQoM4Li3uNIqxSnSPxU/7Cq/d8mcDRVDtfyVZf1/OOrW1tT+uapKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0357
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 May 2020 23:13:11 -0000

--_000_DM6PR00MB0684E59FE5A75B15E1C432C6F5B60DM6PR00MB0684namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBkaXNhZ3JlZSB3aXRoIHRoZSBsYW5ndWFnZSBiZWxvdy4gIEl04oCZcyBwZXJmZWN0bHkgbGVn
YWwgdG8gc3dpdGNoLCBhcyB0aGUgc2FtZSBjbGllbnQgbWF5IGRvIGJvdGggT3BlbklEIENvbm5l
Y3QgYW5kIHB1cmUgT0F1dGggaW50ZXJhY3Rpb25zLCBkZXBlbmRpbmcgdXBvbiB3aGV0aGVyIHRo
ZSDigJxvcGVuaWTigJ0gc2NvcGUgaXMgaW5jbHVkZWQuICBCb3RoIGNhbiBiZSBzZWN1cmUuDQoN
CklmIHRoZSBPcGVuSUQgQ29ubmVjdCBgbm9uY2VgIGlzIHVzZWQgdG8gbWl0aWdhdGUgYXV0aG9y
aXphdGlvbiBjb2RlDQppbmplY3Rpb24gaW5zdGVhZCBvZiBgY29kZV9jaGFsbGVuZ2VgLCBjbGll
bnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyDQpNVVNUIGVuc3VyZSB0aGF0IHRoZSBtaXRpZ2F0
aW9uIGlzIGFwcGxpZWQgdG8gZXZlcnkgaW50ZXJhY3Rpb24gd2l0aA0KdGhlIGNsaWVudCBhbmQg
dGhhdCB0aGUgY2xpZW50IGNhbm5vdCBzd2l0Y2ggYmV0d2VlbiBgY29kZV9jaGFsbGVuZ2VgDQph
bmQgYG5vbmNlYC4gRm9yIGV4YW1wbGUsIHRoZSBwcmVzZW5jZSBvZiBhIGBub25jZWAgcGFyYW1l
dGVyIGluIHRoZQ0KYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIG5vdCBzdWZmaWNpZW50IHRvIGRl
dGVybWluZSB0aGF0IHRoZQ0KYGNvZGVfdmVyaWZpZXJgIGNoZWNrIGNhbiBiZSBza2lwcGVkLg0K
DQpJ4oCZZCByYXRoZXIgdGhhdCB0aGUgb251cyBiZSBwdXQgb24gbmV3IGNvZGUsIHRoYW4gZXhp
c3RpbmcgY29kZS4gIEZvciBpbnN0YW5jZSBuZXcgY29kZSB3YW50aW5nIHRvIHJlcXVpcmUgUEtD
RSBvbiBhbGwgaW50ZXJhY3Rpb25zIGNvdWxkIHVzZSBzb21ldGhpbmcgbGlrZSBhIOKAnHJlcXVp
cmVfcGtjZeKAnSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gcGFyYW1ldGVyIChvciBjb3Jy
ZXNwb25kaW5nIHN0YXRpYyByZWdpc3RyYXRpb24pLiAgT3RoZXJ3aXNlLCBpdCBzaG91bGQgYmUg
dXAgdG8gdGhlIGNsaWVudCB3aGljaCBvZiB0aGUgbWVjaGFuaXNtcyB0byB1c2UuDQoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAtLSBNaWtlDQoNCkZyb206IEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPg0KU2Vu
dDogV2VkbmVzZGF5LCBNYXkgMjAsIDIwMjAgMzo0OCBQTQ0KVG86IE5vdiBNYXRha2UgPG1hdGFr
ZUBnbWFpbC5jb20+DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
Pjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gcHJv
cG9zZWQgcmVzb2x1dGlvbiBmb3IgUEtDRSBpbiBPQXV0aCAyLjENCg0KU28gaWYgSSdtIHVuZGVy
c3RhbmRpbmcgdGhpcyBjb3JyZWN0bHksIGl0IHNvdW5kcyBsaWtlIHRoZSBBUyBuZWVkcyB0byBy
ZWplY3QgYSB0b2tlbiByZXF1ZXN0IHdpdGggY29kZV92ZXJpZmllciBpZiB0aGUgYXV0aG9yaXph
dGlvbiBjb2RlIHdhcyBpc3N1ZWQgaW4gcmVzcG9uc2UgdG8gYSByZXF1ZXN0IHRoYXQgZGlkIG5v
dCBjb250YWluIGEgY29kZV9jaGFsbGVuZ2UuIFRoaXMgdG8gbWUgc291bmRzIGxpa2UgaXQgd291
bGQgYmUgc2ltcGxlciB0byBqdXN0IHNheSB0aGUgY29kZV9jaGFsbGVuZ2UgYW5kIGNvZGVfdmVy
aWZpZXIgYXJlIGFsd2F5cyByZXF1aXJlZC4NCg0KVGhhdCBzYWlkLCBJIGRvIHVuZGVyc3RhbmQg
dGhlIHByZXZpb3VzbHkgZGlzY3Vzc2VkIGNvbmNlcm5zIGFyb3VuZCBleGlzdGluZyBPcGVuSUQg
Q29ubmVjdCBjbGllbnRzLg0KDQpJIGJlbGlldmUgdGhlIHRleHQgdGhhdCBEYW5pZWwgcHJvcG9z
ZWQgaXMgdGhlIGJlc3Qgb2YgYm90aCB3b3JsZHMsIGFuZCBJIHN1cHBvcnQgbWFraW5nIHRoaXMg
Y2hhbmdlIGluIGJvdGggT0F1dGggMi4xIGFuZCB0aGUgU2VjdXJpdHkgQkNQLg0KDQpBYXJvbiBQ
YXJlY2tpDQoNCg0KDQpPbiBUdWUsIE1heSAxOSwgMjAyMCBhdCA5OjI5IEFNIE5vdiBNYXRha2Ug
PG1hdGFrZUBnbWFpbC5jb208bWFpbHRvOm1hdGFrZUBnbWFpbC5jb20+PiB3cm90ZToNClllcy4N
Cg0KVGhlIHJvb3QgcHJvYmxlbSBpc27igJl0IHRoZSBtaXgtdXNlIG9mIFBLQ0UgYW5kIG5vbmNl
LCBpdOKAmXMgUEtDRSBpbXBsZW1lbnRhdGlvbiBidWcuDQpZZWFoLCBhbGwgUEtDRSBpbXBsZW1l
bnRhdGlvbiBNVVNUIHJlamVjdCBzdWNoIHJlcXVlc3RzLCByZWdhcmRsZXNzIGl04oCZcyBPQXV0
aCAyLjEgb3IgMi4wLg0KDQooYW5kIGl04oCZcyBwcm9iYWJseSBiZWNhdXNlIG9mIFBLQ0Ugc3Bl
Y+KAmXMgYW1iaWd1aXR5Li4pDQoNCg0KMjAyMC8wNS8yMCAxOjEz44CBTWlrZSBKb25lcyA8TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20+PuOBruODoeODvOODqzoNCg0KU28gaXQgc291bmRzIG1lIGxpa2UgdGhlIGZpeCBpcyB0byBo
YXZlIHNlcnZlcnMgcmVqZWN0IFBLQ0UgcmVxdWVzdHMgd2l0aCBpbmNvbXBsZXRlIHBhcmFtZXRl
ciBzZXRzOiByZXF1ZXN0cyB0aGF0IG9ubHkgY29udGFpbnMgb25lIG9mIGNvZGVfY2hhbGxlbmdl
IGFuZCBjb2RlX3ZlcmlmaWVkLiAgV2lsbCB0aGF0IGVsaW1pbmF0ZSB0aGUgYXR0YWNrLCBOb3Y/
DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE5vdiBNYXRha2UNClNlbnQ6IE1v
bmRheSwgTWF5IDE4LCAyMDIwIDExOjUwIFBNDQpUbzogRGFuaWVsIEZldHQgPGZldHRAZGFuaWVs
ZmV0dC5kZTxtYWlsdG86ZmV0dEBkYW5pZWxmZXR0LmRlPj4NCkNjOiBvYXV0aEBpZXRmLm9yZzxt
YWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBwcm9wb3NlZCBy
ZXNvbHV0aW9uIGZvciBQS0NFIGluIE9BdXRoIDIuMQ0KDQpTdXJlLCBmZWVsIGZyZWUgdG8gYWRk
IHRoZSBzZW5hcmlvIHRvIHlvdXIgcG9zdC4NCg0KRllJOg0KbXkgT0F1dGgyIHNlcnZlciBydWJ5
IGdlbSByZWplY3RzIHN1Y2ggdG9rZW4gcmVxdWVzdHMsDQpodHRwczovL2dpdGh1Yi5jb20vbm92
L3JhY2stb2F1dGgyL2Jsb2IvbWFzdGVyL2xpYi9yYWNrL29hdXRoMi9zZXJ2ZXIvZXh0ZW5zaW9u
L3BrY2UucmIjTDI4DQphbmQgR29vZ2xlIGFsc28gZG9lcyB0aGUgc2FtZS4NCmh0dHBzOi8vZ2lz
dC5naXRodWIuY29tL25vdi85ZmViYTg2Njg1YmQzYjE4YjRiZjdiZmI4ODAyMjA0Ng0KDQpTbyBJ
J20gZ3Vlc3Npbmcgc3VjaCBiZWhhdmlvciBpcyByZWxhdGl2ZWx5IHJhcmUtY2FzZSwgaG9wZWZ1
bGx5Lg0KDQppUGFk44GL44KJ6YCB5L+hDQoNCjIwMjAvMDUvMTkgMTU6NDPjgIFEYW5pZWwgRmV0
dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPG1haWx0bzpmZXR0QGRhbmllbGZldHQuZGU+PuOBruODoeOD
vOODqzoNCu+7vw0KSGksDQoNCkFtIDE5LjA1LjIwIHVtIDA0OjU1IHNjaHJpZWIgTm92IE1hdGFr
ZToNCkkgdGhvdWdodCB0aGUgc2VydmVyIE1VU1QgcmVqZWN0IHN1Y2ggdG9rZW4gcmVxdWVzdHMs
IGJ1dCBJIGNvdWxkbuKAmXQgZmluZCBzdWNoIGRlZmluaXRpb24gaW4gUkZDNzYzNi4uLg0KDQo+
IFRoZSBjbGllbnQgd2lsbCBzZW5kIHRoZSBjb2RlLCBhbG9uZyB3aXRoIGEgKG5vdyBub3QgbWF0
Y2hpbmcpIGNvZGVfdmVyaWZpZXIgdG8gdGhlIHNlcnZlci4gVGhlIHNlcnZlciB3aWxsIGlnbm9y
ZSB0aGUgY29kZV92ZXJpZmllciAoYXMgaXQgd2FzIG5vdCBleHBlY3RlZCkgYW5kIHNlbmQgYmFj
ayBhbiBhY2Nlc3MgdG9rZW4gYW5kIElEIHRva2VuIHRvIHRoZSBjbGllbnQuDQpodHRwczovL2Rh
bmllbGZldHQuZGUvMjAyMC8wNS8xNi9wa2NlLXZzLW5vbmNlLWVxdWl2YWxlbnQtb3Itbm90LyNu
b25jZXBrY2Utc2lkZXN0ZXAtYXR0YWNrDQoNCklmIHRoZSBiZWhhdmlvciBpcyBhY2NlcHRhYmxl
IGJ5IFJGQzc2MzYsICJOb25jZS9QS0NFIFNpZGVzdGVwIEF0dGFja+KAnSB3b3VsZCBiZSBwb3Nz
aWJsZS4NCg0KSSAqdGhpbmsqIHRoYXQgdGhlcmUgaXMgbm90aGluZyBwcmV2ZW50aW5nIHNlcnZl
cnMgZnJvbSBzb21ldGltZXMgdXNpbmcgUEtDRSBhbmQgc29tZXRpbWVzIHVzaW5nIE5vbmNlLiBJ
IGFzc3VtZSB0aGF0IHRoaXMgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGUgZXhpc3Rpbmcgc3Bl
Y2lmaWNhdGlvbnMuDQoNCkkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBoZWFyIGhvdyBhY3R1YWwg
aW1wbGVtZW50YXRpb25zIGhhbmRsZSB0aGlzIGluIHByYWN0aWNlLg0KDQpQbHVzLCB3aXRoIHN1
Y2ggQVMgYmVoYXZpb3IsIENTUkYgcHJvdGVjdGlvbiB1c2luZyBQS0NFIGNhbiBhbHNvIGJlIGJ5
cGFzc2VkIGFzIGJlbG93Lg0KMS4gVGhlIGF0dGFja2VyIHJlbW92ZXMgY29kZV9jaGFsbGVuZ2Ug
ZnJvbSBoaXMvaGVyIG93biBBdXRoWiBSZXEsIHJlY2VpdmVzIGEgbm9uLWNvZGVfY2hhbGxlbmdl
LWJvdW5kIGNvZGUsIGFuZCBzZW5kcyBpdCB0byB0aGUgdmljdGltLg0KMi4gVGhlIGNsaWVudCBy
ZWNlaXZlcyB0aGUgYXR0YWNrZXLigJlzIGNvZGUgZnJvbSB0aGUgdmljdGltLCBhbmQgc2VuZHMg
aXQgdG8gdGhlIEFTIHcvIHRoZSB2YWxpZCBjb2RlX3ZlcmlmaWVyIGJvdW5kIHRvIHRoZSB2aWN0
aW3igJlzIGJyb3dzZXIgc2Vzc2lvbi4NCjMuIFRoZSBBUyBpZ25vcmVzIHRoZSBjb2RlX3Zlcmlm
aWVyIGFuZCByZXR1cm5zIHRva2Vucy4NCg0KSWYgdGhhdOKAmXMgdGhlIGNhc2UsIGN1cnJlbnQg
T0F1dGggMi4wIFBLQ0UgaW1wbGVtZW50YXRpb24gY2FuIGJlIHdlYWtlciB0aGFuIGV4cGVjdGVk
Li4NCg0KRXhjZWxsZW50IHBvaW50IQ0KDQpXb3VsZCBpdCBiZSBva2F5IGlmIEkgYWRkIHRoYXQg
YXR0YWNrIHRvIHRoZSBvcmlnaW5hbCBwb3N0ICh3aXRoIGNyZWRpdHMsIG9mIGNvdXJzZSk/DQoN
Ci1EYW5pZWwNCg0Kbm92DQoNCjIwMjAvMDUvMTkgMTo1NOOAgURhbmllbCBGZXR0IDxmZXR0QGRh
bmllbGZldHQuZGU8bWFpbHRvOmZldHRAZGFuaWVsZmV0dC5kZT4+44Gu44Oh44O844OrOg0KDQpI
aSBhbGwsDQoNClRhbGtpbmcgdG8gVG9yc3Rlbiwgd2UgcmVhbGl6ZWQgdGhhdCBwcm92aWRpbmcg
YSBnZW5lcmljIGV4dGVuc2lvbiBwb2ludCBoZXJlIGlzIHByb2JhYmx5IG5vdCBhIGdvb2QgaWRl
YS4gSXQgaXMgcmVhbGx5IGhhcmQgdG8gdGVsbCB3aGF0IHByb3RlY3RzIHlvdSBmcm9tIGNvZGUg
aW5qZWN0aW9uIGFuZCB3aGF0IGRvZXMgbm90LCBhbmQgcGVvcGxlIG1pZ2h0IGNvbWUgdXAgd2l0
aCBhbGwgc29ydHMgb2Ygbm9uLXN0YW5kYXJkIGFuZCBwb3RlbnRpYWxseSBpbnNlY3VyZSBzb2x1
dGlvbnMuDQoNCkV2ZW4ganVzdCBmb3IgUEtDRSB2cy4gTm9uY2UsIGl0IGlzIG5vdCBvYnZpb3Vz
IGlmIHRoZXkgcHJvdmlkZSB0aGUgc2FtZSBsZXZlbCBvZiBwcm90ZWN0aW9uLiBJbiBhbiBhdHRl
bXB0IHRvIGFuc3dlciB0aGlzIHF1ZXN0aW9uLCBJIHRyaWVkIHRvIGNvbWUgdXAgd2l0aCBhIG1v
cmUgc3lzdGVtYXRpYyBhbmFseXNpcyBvZiAiUEtDRSB2cyBOb25jZSIuIEkgd3JvdGUgdXAgbXkg
cmVzdWx0cyBoZXJlOg0KaHR0cHM6Ly9kYW5pZWxmZXR0LmRlLzIwMjAvMDUvMTYvcGtjZS12cy1u
b25jZS1lcXVpdmFsZW50LW9yLW5vdC8NCg0KQWx0aG91Z2ggdGhpcyBpcyBub3QgYSBmb3JtYWwg
YW5hbHlzaXMsIEkgaG9wZSB0aGF0IEkgaGF2ZSBjb3ZlcmVkIGFsbCBpbnRlcmVzdGluZyBjYXNl
cy4gUGxlYXNlIHJldmlldyB0aGUgdGV4dCBhbmQgbGV0IG1lIGtub3cgaWYgSSBoYXZlIG1pc3Nl
ZCBzb21ldGhpbmcgb3IgaWYgdGhlcmUgYXJlIGFueSBtaXN0YWtlcy4NCg0KVGhlIG1haW4gcmVz
dWx0cyBhcmU6DQoNCiAgMS4gIEluIHRlcm1zIG9mIHByb3RlY3Rpb24gYWdhaW5zdCBDU1JGIGFu
ZCBjb2RlIG1pc3VzZSwgUEtDRSBhbmQgTm9uY2UgcHJvdmlkZSBzaW1pbGFyIGxldmVscyBvZiBz
ZWN1cml0eSwgd2l0aCBhIHNsaWdodCBhZHZhbnRhZ2UgZm9yIFBLQ0UuDQogIDIuICBJbiBwcmFj
dGljZSwgYSBjaXJjdW12ZW50aW9uIG9mIGJvdGggbWVjaGFuaXNtcywgaG93ZXZlciwgaXMgcG9z
c2libGUgaWYgYW4gQVMgYWxsb3dzIGEgY2xpZW50IHRvIGNob29zZSBiZXR3ZWVuIFBLQ0UgYW5k
IE5vbmNlIGFuZCB0aGUgY2xpZW50IG1ha2VzIHVzZSBvZiB0aGlzIGZyZWVkb20uIEkgcHJvcG9z
ZSB0byBjYWxsIHRoaXMgYXR0YWNrIHRoZSBOb25jZS9QS0NFIFNpZGVzdGVwIEF0dGFjay4g4oaS
IFBsZWFzZSByZXZpZXcgdGhlIGF0dGFjayBkZXNjcmlwdGlvbiBpbiB0aGUgYW5hbHlzaXMuDQog
IDMuICBUbyBhdm9pZCB0aGUgTm9uY2UvUEtDRSBTaWRlc3RlcCBBdHRhY2ssIGNsaWVudHMgbXVz
dCBub3Qgc3dpdGNoIGJldHdlZW4gdXNpbmcgb25seSBQS0NFIGFuZCBvbmx5IE5vbmNlIChidXQg
bWF5IHVzZSBib3RoIGluIHBhcmFsbGVsLCBvciBzd2l0Y2ggYmV0d2VlbiB1c2luZyBvbmx5IFBL
Q0UgYW5kIFBLQ0UrTm9uY2UpLiBBdXRob3JpemF0aW9uIHNlcnZlcnMgbXVzdCBlbmZvcmNlIFBL
Q0UgdW5sZXNzIHRoZXkga25vdyB0aGF0IHRoZSBjbGllbnQgdXNlcyBOb25jZSBmb3IgYWxsIG9m
IGl0cyBmbG93cyAoYW5kIGNoZWNrcyB0aGUgTm9uY2UgdmFsdWUpLiBUaGUgcHJlc2VuY2Ugb2Yg
YSBub25jZSBwYXJhbWV0ZXIgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBub3Qgc3Vm
ZmljaWVudCB0byBkZXRlcm1pbmUgaWYgYSBjbGllbnQgYWN0dWFsbHkgY2hlY2tzIHRoZSBub25j
ZSBjbGFpbSBpbiB0aGUgSUQgdG9rZW4uDQpBcyB5b3UgY2FuIHNlZSwgYWxyZWFkeSBoYXZpbmcg
dHdvIG1vcmUtb3ItbGVzcyB3ZWxsLXVuZGVyc3Rvb2QgbWVjaGFuaXNtcyBpcyBoYXJkIGVub3Vn
aCB0byB3cmFwIHlvdXIgaGVhZCBhcm91bmQgZnJvbSBhIHNlY3VyaXR5IHN0YW5kcG9pbnQuIFdl
IHNob3VsZCB0aGVyZWZvcmUgbWFrZSBQS0NFIHRoZSBkZWZhdWx0IGFuZCBOb25jZSBhbiBvcHRp
b24gZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5Lg0KVG8gdGhpcyBlbmQsIEkgd291bGQgbGlr
ZSB0byBwcm9wb3NlIHRoZSBmb2xsd2luZyBzdHJhd21hbiwgYmFzZWQgb24gVG9yc3RlbidzIGFu
ZCBBYXJvbidzIHN1Z2dlc3Rpb25zOg0KQW4gQVMgTVVTVCByZWplY3QgcmVxdWVzdHMgd2l0aG91
dCBhIGNvZGVfY2hhbGxlbmdlIGZyb20gcHVibGljDQpjbGllbnRzLCBhbmQgTVVTVCByZWplY3Qg
c3VjaCByZXF1ZXN0cyBmcm9tIG90aGVyIGNsaWVudHMgdW5sZXNzIHRoZXJlDQppcyByZWFzb25h
YmxlIGFzc3VyYW5jZSB0aGF0IHRoZSBjbGllbnQgbWl0aWdhdGVzIGF1dGhvcml6YXRpb24gY29k
ZQ0KaW5qZWN0aW9uIHVzaW5nIHRoZSBPcGVuSUQgQ29ubmVjdCBOb25jZSBtZWNoYW5pc20gYW5k
IHRoYXQgdGhpcw0KbWl0aWdhdGlvbiBpcyB1c2VkIGZvciBhbGwgaW50ZXJhY3Rpb25zIHdpdGgg
dGhlIGNsaWVudC4gU2VlIHNlY3Rpb24NCjkuNyBmb3IgZGV0YWlscy4NCg0KU2VjdGlvbiA5Ljc6
DQoNCkNsaWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlvbiAocmVwbGF5KSBvZiBhdXRob3JpemF0
aW9uIGNvZGVzIGludG8NCnRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlIGJ5IGF0dGFja2Vycy4g
VGhlIHVzZSBvZiB0aGUNCmBjb2RlX2NoYWxsZW5nZWAgcGFyYW1ldGVyIGlzIFJFQ09NTUVOREVE
IHRvIHRoaXMgZW5kLiBGb3INCmNvbmZpZGVudGlhbCBjbGllbnRzLCB0aGUgT3BlbklEIENvbm5l
Y3QgYG5vbmNlYCBwYXJhbWV0ZXIgYW5kIElEDQpUb2tlbiBDbGFpbSB7e09wZW5JRH19IE1BWSBi
ZSB1c2VkIGluc3RlYWQgb2Ygb3IgaW4gYWRkaXRpb24gdG8gdGhlDQpgY29kZV9jaGFsbGVuZ2Vg
IHBhcmFtZXRlciBmb3IgdGhpcyBwdXJwb3NlLiBUaGUgYGNvZGVfY2hhbGxlbmdlYCBvcg0KT3Bl
bklEIENvbm5lY3QgYG5vbmNlYCB2YWx1ZSBNVVNUIGJlIHRyYW5zYWN0aW9uLXNwZWNpZmljIGFu
ZCBzZWN1cmVseQ0KYm91bmQgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVzZXIgYWdlbnQgaW4gd2hp
Y2ggdGhlIHRyYW5zYWN0aW9uIHdhcw0Kc3RhcnRlZC4NCg0KSWYgdGhlIE9wZW5JRCBDb25uZWN0
IGBub25jZWAgaXMgdXNlZCB0byBtaXRpZ2F0ZSBhdXRob3JpemF0aW9uIGNvZGUNCmluamVjdGlv
biBpbnN0ZWFkIG9mIGBjb2RlX2NoYWxsZW5nZWAsIGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXINCk1VU1QgZW5zdXJlIHRoYXQgdGhlIG1pdGlnYXRpb24gaXMgYXBwbGllZCB0byBldmVy
eSBpbnRlcmFjdGlvbiB3aXRoDQp0aGUgY2xpZW50IGFuZCB0aGF0IHRoZSBjbGllbnQgY2Fubm90
IHN3aXRjaCBiZXR3ZWVuIGBjb2RlX2NoYWxsZW5nZWANCmFuZCBgbm9uY2VgLiBGb3IgZXhhbXBs
ZSwgdGhlIHByZXNlbmNlIG9mIGEgYG5vbmNlYCBwYXJhbWV0ZXIgaW4gdGhlDQphdXRob3JpemF0
aW9uIHJlcXVlc3QgaXMgbm90IHN1ZmZpY2llbnQgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlDQpgY29k
ZV92ZXJpZmllcmAgY2hlY2sgY2FuIGJlIHNraXBwZWQuDQoNCk9mIGNvdXJzZSwgd2UgbmVlZCB0
byBhZGFwdCB0aGUgd29yZGluZyBpbiB0aGUgU2VjdXJpdHkgQkNQIGFjY29yZGluZ2x5Lg0KLURh
bmllbA0KDQoNCkFtIDE1LjA1LjIwIHVtIDAxOjAxIHNjaHJpZWIgTWlrZSBKb25lczoNCg0KSSBh
Z3JlZSB3aXRoIE5vdiB0aGF0IG9ic2N1cmluZyB0aGUgbGFuZ3VhZ2UgaW4gOS43IHdvdWxkIGJl
IGEgZGlzc2VydmljZSB0byBkZXZlbG9wZXJzLg0KDQoNCg0KVGhlIFNlY3VyaXR5IEJDUCwgd2hp
Y2ggaGFzIGFscmVhZHkgZ29pbmcgdGhlIFdHTEMsIGV4cGxpY2l0bHkgY2FsbHMgb3V0IHRoZSB1
c2Ugb2Ygbm9uY2UgYXMgcGFydCBvZiB0aGUgYmVzdCBwcmFjdGljZXMuICBPQXV0aCAyLjEgc2hv
dWxkIGRvIG5vIGxlc3MuDQoNCg0KDQpUaGUgOS43IGxhbmd1YWdlIHRoYXQgQWFyb24gcHJvcG9z
ZWQgd2FzIHRoZSByZXN1bHQgb2YgbWFueSBwZW9wbGUncyBjb250cmlidXRpb25zIGFuZCBhIHZp
Z29yb3VzIGRpc2N1c3Npb24uICBMZXQncyBwdWJsaXNoIHRoZSBuZXh0IHZlcnNpb24gb2YgMi4x
IHdpdGggdGhhdCBsYW5ndWFnZSBpbnRhY3QsIGFzIEkgYmVsaWV2ZSBpdCByZXByZXNlbnRzIGF0
IGxlYXN0IGEgbG9jYWwgcG9pbnQgb2YgaGFyZC13b24gY29uc2Vuc3VzLiAgTGV0J3MgZ2V0IHRo
YXQgbGFuZ3VhZ2UgaW50byB0aGUgcmVjb3JkIG9mIGRyYWZ0cy4NCg0KDQoNClRoZXJlJ3MgYWx3
YXlzIHRpbWUgdG8gZGViYXRlIGl0IGFuZCBjaGFuZ2UgaXQgbGF0ZXIgaW4gc3Vic2VxdWVudCBk
cmFmdHMsIGJ1dCBsZXQncyBub3Qgbm93IGxvc2Ugd2hhdCBpdCB0b29rIGEgbG90IG9mIGVmZm9y
dCB0byBhY2hpZXZlLg0KDQoNCg0KICAgIFRoYW5rcywNCg0KICAgIC0tIE1pa2UNCg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IE5vdiBNYXRha2UgPG1hdGFrZUBnbWFp
bC5jb20+PG1haWx0bzptYXRha2VAZ21haWwuY29tPg0KDQpTZW50OiBUaHVyc2RheSwgTWF5IDE0
LCAyMDIwIDM6MTggQU0NCg0KVG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVy
c3RlZHQubmV0PjxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+DQoNCkNjOiBPQXV0aCBX
RyA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz47IE1pa2UgSm9uZXMgPE1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbT4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcHJvcG9zZWQgcmVzb2x1dGlvbiBmb3Ig
UEtDRSBpbiBPQXV0aCAyLjENCg0KDQoNClRoZXJlIGlzIG5vIHNwZWNpZmljIG1lY2hhbmlzbSBy
aWdodCBub3cuDQoNCkJ1dCBmdXR1cmUgZGV2ZWxvcGVycyB3b27igJl0IGJlIGFibGUgdG8gcmVh
ZCB0aGUgcmVhc29uIHdoeSB0aGUgZXh0ZW5zaW9uIHBvaW50IGlzIGdpdmVuIG9ubHkgZm9yIGNv
bmZpZGVudGlhbCBjbGllbnRzLg0KDQoNCg0KT24gTWF5IDE0LCAyMDIwLCBhdCAxODozMiwgVG9y
c3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PG1haWx0bzp0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQoNCg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBzdWl0
YWJsZSBtZWNoYW5pc20/IEnigJltIGFza2luZyBzaW5jZSBmcm9tIG15IHBlcnNwZWN0aXZlIHRo
aXMgY2xhdXNlIGlzIG1haW5seSBpbnRlbmRlZCB0byBhbGxvdyBleGlzdGluZyBPcGVuSUQgQ29u
bmVjdCBkZXBsb3ltZW50cyB0byB1c2Ugbm9uY2UgaW5zdGVhZCBvZiBQS0NFIGluIGNvbWJpbmF0
aW9uIHdpdGggT0F1dGggMi4xLiBJdOKAmXMgYSBjb21wcm9taXNlLiBJIHRoaW5rIHdlIHNob3Vs
ZCBub3QgZW5jb3VyYWdlIG90aGVycyB0byBpbnZlbnQgdGhlaXIgb3duIE9BdXRoIHNlY3VyaXR5
IG1lY2hhbmlzbXMuDQoNCg0KDQpPbiAxNC4gTWF5IDIwMjAsIGF0IDA5OjM3LCBOb3YgTWF0YWtl
IDxtYXRha2VAZ21haWwuY29tPjxtYWlsdG86bWF0YWtlQGdtYWlsLmNvbT4gd3JvdGU6DQoNCg0K
DQpIaSwNCg0KDQoNCldoeSBub3QgYWxsb3dpbmcgcHVibGljIGNsaWVudHMgdXNlICJvdGhlciBz
dWl0YWJsZSBtZWNoYW5pc21z4oCdIHRoZW4/DQoNCk9BdXRoIFdHIGNhbiBhbGxvdyBib3RoIHR5
cGUgb2YgY2xpZW50cyBkbyBzbywgdGhlbiBPSURGIHdpbGwgZGVmaW5lIG5vbmNlIGFzIHRoZSBh
bHRlcm5hdGl2ZSBvbmx5IGZvciBjb25maWRlbnRpYWwgY2xpZW50cy4NCg0KDQoNCjIwMjAvMDUv
MTQgMTU6NTbjgIFUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0
QGRtYXJjLmlldGYub3JnPjxtYWlsdG86dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5p
ZXRmLm9yZz7jga7jg6Hjg7zjg6s6DQoNCg0KDQpIaSBhbGwsDQoNCg0KDQpJIHdvdWxkIGFsc28g
bGlrZSB0byB0aGFuayBldmVyeWJvZHkgZm9yIHRoZSBzdWJzdGFudGlhbCBkaXNjdXNzaW9uLg0K
DQoNCg0KVGhlIHByb3Bvc2VkIGNoYW5nZSBmb3IgU2VjdGlvbiA0LjEuMi4xIHdvcmtzIGZvciBt
ZSAoYXMgYWxyZWFkeSBzdGF0ZWQpLiBJ4oCZbSBub3QgZnVsbHkgY29tZm9ydGFibGUgd2l0aCB0
aGUgcHJvcG9zZWQgY2hhbmdlIGZvciBTZWN0aW9uIDkuNyBmb3IgdGhlIGZvbGxvd2luZyByZWFz
b25zOg0KDQoNCg0KLSBUaGUgdGV4dCBpcyB3ZWFrZXIgdGhhbiBTZWN0aW9uIDQuMS4yLjEgc2lu
Y2UgaXQgUkVDT01NRU5EUyB1c2Ugb2YgUEtDRSBpbnN0ZWFkIG9mIHJlcXVpcmluZyBpdCAod2l0
aCBhIHdlbGwtZGVmaW5lZCBleGNlcHRpb24pLg0KDQotIEdpdmVuIHRoZSBsYXRlc3QgZmluZGlu
Z3MgcmUgbm9uY2UgSSBkb27igJl0IGZlZWwgY29tZm9ydGFibGUgd2l0aCByZWNvbW1lbmRpbmcg
YW55IG1lY2hhbmlzbSB0aGF0IHRoaXMgV0cgaXMgbm90IHJlc3BvbnNpYmxlIGZvciBhbmQgdGh1
cyBkaWQgbm90IGNvbmR1Y3QgdGhlIHNlY3VyaXR5IHRocmVhdCBhbmFseXNpcyBmb3IuIEkgdGhp
bmsgdGhlIGJldHRlciB3YXkgZm9yIHVzIGFzIFdHIGlzIHRvIGRlZmluZSB0aGUgZXh0ZW5zaW9u
IHBvaW50IGZvciBvdGhlciBtZWNoYW5pc21zLiBUaGUgT3BlbklEIEZvdW5kYXRpb24gKG9yIGFu
eSBvdGhlciBib2R5KSBjYW4gdGhlbiBmaWxsIGluIGFuZCBpc3N1ZSBhIHN0YXRlbWVudCB0aGF0
IG5vbmNlIChvciBhbm90aGVyIHN1aXRhYmxlIG1lY2hhbmlzbSkgZnVsZmlscyB0aGUgcmVxdWly
ZW1lbnRzIG9mIHRoZSBleHRlbnNpb24gcG9pbnQuDQoNCg0KDQpCYXNlZCBvbiB0aGlzIGNvbnNp
ZGVyYXRpb25zLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IGZvciBTZWN0aW9uIDkuNzoN
Cg0KDQoNCkNsaWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlvbiAocmVwbGF5KSBvZiBhdXRob3Jp
emF0aW9uIGNvZGVzIGludG8NCg0KdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgYnkgYXR0YWNr
ZXJzLiBQdWJsaWMgY2xpZW50cyBNVVNUIHVzZSB0aGUNCg0KImNvZGVfY2hhbGxlbmdl4oCdIHdp
dGggYSB0cmFuc2FjdGlvbi1zcGVjaWZpYyB2YWx1ZSB0aGF0IGlzIHNlY3VyZWx5DQoNCmJvdW5k
IHRvIHRoZSBjbGllbnQgYW5kIHRoZSB1c2VyIGFnZW50IGluIHdoaWNoIHRoZSB0cmFuc2FjdGlv
biB3YXMNCg0Kc3RhcnRlZC4gQ29uZmlkZW50aWFsIGNsaWVudHMgTVVTVCB1c2UgdGhlIOKAnGNv
ZGVfY2hhbGxlbmdl4oCdIGluIHRoZQ0KDQpzYW1lIHdheSBvciBvdGhlciBzdWl0YWJsZSBtZWNo
YW5pc21zIHRvIG1pdGlnYXRlIGF1dGhvcml6YXRpb24gY29kZQ0KDQppbmplY3Rpb24uDQoNCg0K
DQpUaGlzIHRleHQgZm9sbG93cyB0aGUgbG9naWMgaW4gU2VjdGlvbiA0LjEuMi4xIGFuZCBhbGxv
d3MgdXNlIG9mIHRoZSBub25jZSBmb3IgY29uZmlkZW50aWFsIGNsaWVudHMuDQoNCg0KDQpiZXN0
IHJlZ2FyZHMsDQoNClRvcnN0ZW4uDQoNCg0KDQpPbiAxMi4gTWF5IDIwMjAsIGF0IDAyOjIxLCBN
aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz48
bWFpbHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPiB3cm90
ZToNCg0KDQoNClRoYXQgd29ya3MgZm9yIG1lLiAgVGhhbmtzIGFsbCBmb3IgdGhlIHVzZWZ1bCBi
YWNrLWFuZC1mb3J0aCB0aGF0IGdvdCB1cyB0byB0aGlzIHBvaW50IG9mIGNsYXJpdHkuICBJIHN1
c3BlY3QgbWFueSBvZiB1cyBsZWFybmVkIHRoaW5ncyBhbG9uZyB0aGUgd2F5OyBJIGtub3cgdGhh
dCBJIGRpZCENCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBDaGVlcnMsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQpGcm9tOiBBYXJvbiBQYXJlY2tpIDxhYXJv
bkBwYXJlY2tpLmNvbT48bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPg0KDQpTZW50OiBNb25kYXks
IE1heSAxMSwgMjAyMCA0OjU1IFBNDQoNClRvOiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+PG1h
aWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KQ2M6IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3Jn
ZXJvY2suY29tPjxtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT47IE1pa2UgSm9uZXMN
Cg0KPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbT4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcHJvcG9zZWQgcmVzb2x1dGlv
biBmb3IgUEtDRSBpbiBPQXV0aCAyLjENCg0KDQoNClRoYW5rIHlvdSBOZWlsLg0KDQoNCg0KVG8g
YWRkcmVzcyBNaWtlJ3MgY29uY2VybnMgaW4gdGhlIHByZXZpb3VzIHRocmVhZHMsIEkgd291bGQg
bGlrZSB0byBhbHNvIHVwZGF0ZSBzZWN0aW9uIDkuNyB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dDoN
Cg0KDQoNCkNsaWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlvbiAocmVwbGF5KSBvZiBhdXRob3Jp
emF0aW9uIGNvZGVzIGludG8NCg0KdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgYnkgYXR0YWNr
ZXJzLiBUaGUgdXNlIG9mIHRoZQ0KDQpgY29kZV9jaGFsbGVuZ2VgIHBhcmFtZXRlciBpcyBSRUNP
TU1FTkRFRCB0byB0aGlzIGVuZC4gRm9yDQoNCmNvbmZpZGVudGlhbCBjbGllbnRzLCB0aGUgT3Bl
bklEIENvbm5lY3QgYG5vbmNlYCBwYXJhbWV0ZXIgYW5kIElEDQoNClRva2VuIENsYWltIHt7T3Bl
bklEfX0gTUFZIGJlIHVzZWQgaW5zdGVhZCBvZiBvciBpbiBhZGRpdGlvbiB0byB0aGUNCg0KYGNv
ZGVfY2hhbGxlbmdlYCBwYXJhbWV0ZXIgZm9yIHRoaXMgcHVycG9zZS4gVGhlIGBjb2RlX2NoYWxs
ZW5nZWANCg0Kb3IgT3BlbklEIENvbm5lY3QgYG5vbmNlYCB2YWx1ZSBNVVNUIGJlIHRyYW5zYWN0
aW9uLXNwZWNpZmljIGFuZA0KDQpzZWN1cmVseSBib3VuZCB0byB0aGUgY2xpZW50IGFuZCB0aGUg
dXNlciBhZ2VudCBpbiB3aGljaCB0aGUgdHJhbnNhY3Rpb24gd2FzIHN0YXJ0ZWQuDQoNCg0KDQpU
aGlzIGNoYW5nZSBiZXR0ZXIgY2xhcmlmaWVzIHRoZSBzcGVjaWZpYyBjaXJjdW1zdGFuY2VzIHVu
ZGVyIHdoaWNoIHRoZSAibm9uY2UiIHBhcmFtZXRlciBpcyBzdWZmaWNpZW50IHRvIHByb3RlY3Qg
YWdhaW5zdCBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uLg0KDQoNCg0KQWFyb24gUGFyZWNr
aQ0KDQoNCg0KT24gTW9uLCBNYXkgMTEsIDIwMjAgYXQgMTE6NTUgQU0gTmVpbCBNYWRkZW4gPG5l
aWwubWFkZGVuQGZvcmdlcm9jay5jb20+PG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29t
PiB3cm90ZToNCg0KSSBhbSBoYXBweSB3aXRoIHRoaXMgcHJvcG9zZWQgd29yZGluZy4gVGhhbmtz
IGZvciB1cGRhdGluZyBpdC4NCg0KDQoNCuKAlCBOZWlsDQoNCg0KDQoNCg0KT24gMTEgTWF5IDIw
MjAsIGF0IDE5OjUyLCBBYXJvbiBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT48bWFpbHRvOmFh
cm9uQHBhcmVja2kuY29tPiB3cm90ZToNCg0KDQoNClRoYW5rcyBmb3IgdGhlIGxpdmVseSBkaXNj
dXNzaW9uIGFyb3VuZCBQS0NFIGluIE9BdXRoIDIuMSBldmVyeW9uZSENCg0KDQoNCldlIHdvdWxk
IGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQsIHdoaWNoIGlzIGEgc2xpZ2h0IHZh
cmlhdGlvbiBmcm9tIHRoZSB0ZXh0IE5laWwgcHJvcG9zZWQuIFRoaXMgd291bGQgcmVwbGFjZSB0
aGUgcGFyYWdyYXBoIGluIDQuMS4yLjEgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1wYXJlY2tpLW9hdXRoLXYyLTEtMDIjc2VjdGlvbi00LjEuMi4xKSB0aGF0IGJlZ2lucyB3aXRo
ICJJZiB0aGUgY2xpZW50IGRvZXMgbm90IHNlbmQgdGhlICJjb2RlX2NoYWxsZW5nZSIgaW4gdGhl
IHJlcXVlc3QuLi4iDQoNCg0KDQoiQW4gQVMgTVVTVCByZWplY3QgcmVxdWVzdHMgd2l0aG91dCBh
IGNvZGVfY2hhbGxlbmdlIGZyb20gcHVibGljIGNsaWVudHMsIGFuZCBNVVNUIHJlamVjdCBzdWNo
IHJlcXVlc3RzIGZyb20gb3RoZXIgY2xpZW50cyB1bmxlc3MgdGhlcmUgaXMgcmVhc29uYWJsZSBh
c3N1cmFuY2UgdGhhdCB0aGUgY2xpZW50IG1pdGlnYXRlcyBhdXRob3JpemF0aW9uIGNvZGUgaW5q
ZWN0aW9uIGluIG90aGVyIHdheXMuLiBTZWUgc2VjdGlvbiA5LjcgZm9yIGRldGFpbHMuIg0KDQoN
Cg0KU2VjdGlvbiA5LjcgaXMgd2hlcmUgdGhlIG51YW5jZXMgb2YgUEtDRSB2cyBub25jZSBhcmUg
ZGVzY3JpYmVkLg0KDQoNCg0KQXMgTmVpbCBkZXNjcmliZWQsIHdlIGJlbGlldmUgdGhpcyB3aWxs
IGFsbG93IEFTcyB0byBzdXBwb3J0IGJvdGggT0F1dGggMi4wIGFuZCAyLjEgY2xpZW50cyBzaW11
bHRhbmVvdXNseS4gVGhlIGNoYW5nZSBmcm9tIE5laWwncyB0ZXh0IGlzIHRoZSBjbGFyaWZpY2F0
aW9uIG9mIHdoaWNoIHRocmVhdHMsIGFuZCBjaGFuZ2luZyB0byBNVVNUIGluc3RlYWQgb2YgU0hP
VUxELiBUaGUgIk1VU1QuLi51bmxlc3MiIGlzIG1vcmUgc3BlY2lmaWMgdGhhbiAiU0hPVUxEIiwg
YW5kIHNpbmNlIHdlIGFyZSBhbHJlYWR5IGRlc2NyaWJpbmcgdGhlIGV4cGxpY2l0IGV4Y2VwdGlv
biB0byB0aGUgcnVsZSwgaXQncyBtb3JlIGNsZWFyIGFzIGEgTVVTVCBoZXJlLg0KDQoNCg0KQWFy
b24gUGFyZWNraQ0KDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1h
aWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9B
dXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+
DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg
bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQo=

--_000_DM6PR00MB0684E59FE5A75B15E1C432C6F5B60DM6PR00MB0684namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut
MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy
aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3
IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KdHQNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9y
bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2OTAx
MTAyNDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3NzMyODcxNjg7fQ0Kb2wNCgl7bWFyZ2lu
LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDAyMDYwIj5JIGRpc2FncmVlIHdpdGggdGhlIGxhbmd1YWdlIGJlbG93LiZuYnNwOyBJdOKAmXMg
cGVyZmVjdGx5IGxlZ2FsIHRvIHN3aXRjaCwgYXMgdGhlIHNhbWUgY2xpZW50IG1heSBkbyBib3Ro
IE9wZW5JRCBDb25uZWN0IGFuZCBwdXJlIE9BdXRoIGludGVyYWN0aW9ucywgZGVwZW5kaW5nIHVw
b24gd2hldGhlciB0aGUg4oCcb3Blbmlk4oCdIHNjb3BlIGlzIGluY2x1ZGVkLiZuYnNwOyBCb3Ro
IGNhbg0KIGJlIHNlY3VyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SWYgdGhlIE9wZW5JRCBDb25uZWN0IGBub25j
ZWAgaXMgdXNlZCB0byBtaXRpZ2F0ZSBhdXRob3JpemF0aW9uIGNvZGU8L3NwYW4+PC90dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PGJyPg0KPHR0PmluamVjdGlvbiBpbnN0ZWFkIG9mIGBjb2RlX2NoYWxsZW5nZWAsIGNs
aWVudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8L3R0Pjxicj4NCjx0dD5NVVNUIGVuc3VyZSB0
aGF0IHRoZSBtaXRpZ2F0aW9uIGlzIGFwcGxpZWQgdG8gZXZlcnkgaW50ZXJhY3Rpb24gd2l0aDwv
dHQ+PGJyPg0KPHR0PnRoZSBjbGllbnQgYW5kIHRoYXQgdGhlIGNsaWVudCBjYW5ub3Qgc3dpdGNo
IGJldHdlZW4gYGNvZGVfY2hhbGxlbmdlYDwvdHQ+PGJyPg0KPHR0PmFuZCBgbm9uY2VgLiBGb3Ig
ZXhhbXBsZSwgdGhlIHByZXNlbmNlIG9mIGEgYG5vbmNlYCBwYXJhbWV0ZXIgaW4gdGhlPC90dD48
YnI+DQo8dHQ+YXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIG5vdCBzdWZmaWNpZW50IHRvIGRldGVy
bWluZSB0aGF0IHRoZTwvdHQ+PGJyPg0KPHR0PmBjb2RlX3ZlcmlmaWVyYCBjaGVjayBjYW4gYmUg
c2tpcHBlZC48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SeKAmWQg
cmF0aGVyIHRoYXQgdGhlIG9udXMgYmUgcHV0IG9uIG5ldyBjb2RlLCB0aGFuIGV4aXN0aW5nIGNv
ZGUuJm5ic3A7IEZvciBpbnN0YW5jZSBuZXcgY29kZSB3YW50aW5nIHRvIHJlcXVpcmUgUEtDRSBv
biBhbGwgaW50ZXJhY3Rpb25zIGNvdWxkIHVzZSBzb21ldGhpbmcgbGlrZSBhIOKAnHJlcXVpcmVf
cGtjZeKAnSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gcGFyYW1ldGVyDQogKG9yIGNvcnJl
c3BvbmRpbmcgc3RhdGljIHJlZ2lzdHJhdGlvbikuJm5ic3A7IE90aGVyd2lzZSwgaXQgc2hvdWxk
IGJlIHVwIHRvIHRoZSBjbGllbnQgd2hpY2ggb2YgdGhlIG1lY2hhbmlzbXMgdG8gdXNlLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+RnJvbTo8L2I+IEFhcm9uIFBhcmVja2kgJmx0O2Fhcm9uQHBhcmVja2kuY29tJmd0OyA8YnI+
DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMjAsIDIwMjAgMzo0OCBQTTxicj4NCjxiPlRv
OjwvYj4gTm92IE1hdGFrZSAmbHQ7bWF0YWtlQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+
IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs7IG9hdXRoQGll
dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gcHJv
cG9zZWQgcmVzb2x1dGlvbiBmb3IgUEtDRSBpbiBPQXV0aCAyLjE8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gaWYgSSdtIHVuZGVyc3RhbmRpbmcgdGhpcyBjb3JyZWN0
bHksIGl0IHNvdW5kcyBsaWtlIHRoZSBBUyBuZWVkcyB0byByZWplY3QgYSB0b2tlbiByZXF1ZXN0
IHdpdGggY29kZV92ZXJpZmllciBpZiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHdhcyBpc3N1ZWQg
aW4gcmVzcG9uc2UgdG8gYSByZXF1ZXN0IHRoYXQgZGlkIG5vdCBjb250YWluIGEgY29kZV9jaGFs
bGVuZ2UuIFRoaXMgdG8gbWUgc291bmRzIGxpa2UNCiBpdCB3b3VsZCBiZSBzaW1wbGVyIHRvIGp1
c3Qgc2F5IHRoZSBjb2RlX2NoYWxsZW5nZSBhbmQgY29kZV92ZXJpZmllciBhcmUgYWx3YXlzIHJl
cXVpcmVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh
dCBzYWlkLCBJIGRvIHVuZGVyc3RhbmQgdGhlIHByZXZpb3VzbHkgZGlzY3Vzc2VkIGNvbmNlcm5z
IGFyb3VuZCBleGlzdGluZyBPcGVuSUQgQ29ubmVjdCBjbGllbnRzLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhlIHRleHQg
dGhhdCBEYW5pZWwgcHJvcG9zZWQgaXMgdGhlIGJlc3Qgb2YgYm90aCB3b3JsZHMsIGFuZCBJIHN1
cHBvcnQgbWFraW5nIHRoaXMgY2hhbmdlIGluIGJvdGggT0F1dGggMi4xIGFuZCB0aGUgU2VjdXJp
dHkgQkNQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BYXJvbiBQYXJlY2tpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1heSAxOSwgMjAyMCBhdCA5OjI5IEFNIE5vdiBN
YXRha2UgJmx0OzxhIGhyZWY9Im1haWx0bzptYXRha2VAZ21haWwuY29tIj5tYXRha2VAZ21haWwu
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoZSByb290IHByb2JsZW0gaXNu4oCZdCB0aGUgbWl4LXVzZSBvZiBQS0NF
IGFuZCBub25jZSwgaXTigJlzIFBLQ0UgaW1wbGVtZW50YXRpb24gYnVnLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj5ZZWFoLCBhbGwgUEtDRSBpbXBsZW1lbnRhdGlvbiBNVVNUIHJlamVjdCBzdWNoIHJl
cXVlc3RzLCByZWdhcmRsZXNzIGl04oCZcyBPQXV0aCAyLjEgb3IgMi4wLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj4oYW5kIGl04oCZcyZuYnNwO3Byb2JhYmx5PC9zcGFuPiZuYnNwOzxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+YmVjYXVzZSBvZiBQS0NFIHNwZWPigJlzIGFtYmlndWl0
eS4uKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjIwMjAvMDUvMjAgMToxMzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOAgTwvc3Bhbj5NaWtlIEpvbmVzICZsdDs8YSBocmVmPSJt
YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFl
bC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7TVMgR290aGljJnF1b3Q7Ij7jga7jg6Hjg7zjg6s8L3NwYW4+OjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDAyMDYwIj5TbyBpdCBzb3VuZHMgbWUgbGlrZSB0aGUgZml4IGlzIHRvIGhhdmUgc2VydmVycyBy
ZWplY3QgUEtDRSByZXF1ZXN0cyB3aXRoIGluY29tcGxldGUgcGFyYW1ldGVyIHNldHM6IHJlcXVl
c3RzIHRoYXQgb25seSBjb250YWlucyBvbmUgb2YgY29kZV9jaGFsbGVuZ2UgYW5kIGNvZGVfdmVy
aWZpZWQuJm5ic3A7IFdpbGwgdGhhdCBlbGltaW5hdGUgdGhlIGF0dGFjaywgTm92Pzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2
MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF
MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPkZyb206PC9iPiZuYnNwO09BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmc8L2E+Jmd0OyZuYnNwOzxiPk9uIEJlaGFsZiBPZiZuYnNwOzwvYj5Ob3YgTWF0YWtlPGJyPg0K
PGI+U2VudDo8L2I+Jm5ic3A7TW9uZGF5LCBNYXkgMTgsIDIwMjAgMTE6NTAgUE08YnI+DQo8Yj5U
bzo8L2I+Jm5ic3A7RGFuaWVsIEZldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmZXR0QGRhbmllbGZl
dHQuZGUiIHRhcmdldD0iX2JsYW5rIj5mZXR0QGRhbmllbGZldHQuZGU8L2E+Jmd0Ozxicj4NCjxi
PkNjOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSZTogW09B
VVRILVdHXSBwcm9wb3NlZCByZXNvbHV0aW9uIGZvciBQS0NFIGluIE9BdXRoIDIuMTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlN1cmUsIGZlZWwgZnJlZSB0byBhZGQgdGhlIHNlbmFyaW8gdG8geW91ciBw
b3N0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZZSTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm15IE9BdXRoMiBzZXJ2ZXIgcnVieSBnZW0gcmVqZWN0
cyBzdWNoIHRva2VuIHJlcXVlc3RzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9ub3Yv
cmFjay1vYXV0aDIvYmxvYi9tYXN0ZXIvbGliL3JhY2svb2F1dGgyL3NlcnZlci9leHRlbnNpb24v
cGtjZS5yYiNMMjgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vbm92L3JhY2st
b2F1dGgyL2Jsb2IvbWFzdGVyL2xpYi9yYWNrL29hdXRoMi9zZXJ2ZXIvZXh0ZW5zaW9uL3BrY2Uu
cmIjTDI4PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIEdvb2dsZSBhbHNvIGRvZXMgdGhlIHNhbWUuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YSBocmVmPSJodHRwczovL2dpc3QuZ2l0aHViLmNvbS9ub3YvOWZlYmE4NjY4NWJkM2Ix
OGI0YmY3YmZiODgwMjIwNDYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpc3QuZ2l0aHViLmNv
bS9ub3YvOWZlYmE4NjY4NWJkM2IxOGI0YmY3YmZiODgwMjIwNDY8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlNvIEknbSBndWVzc2luZyBzdWNoIGJlaGF2aW9yIGlzIHJlbGF0aXZlbHkg
cmFyZS1jYXNlLCBob3BlZnVsbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlQYWQ8c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgYvjgonpgIHkv6E8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
MjAyMC8wNS8xOSAxNTo0MzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm
cXVvdDsiPuOAgTwvc3Bhbj5EYW5pZWwgRmV0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZldHRAZGFu
aWVsZmV0dC5kZSIgdGFyZ2V0PSJfYmxhbmsiPmZldHRAZGFuaWVsZmV0dC5kZTwvYT4mZ3Q7PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44Gu44Oh44O844Or
PC9zcGFuPjo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPu+7vyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BbSAxOS4wNS4yMCB1bSAwNDo1NSBzY2hyaWViIE5vdiBNYXRha2U6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91
Z2h0IHRoZSBzZXJ2ZXIgTVVTVCByZWplY3Qgc3VjaCB0b2tlbiByZXF1ZXN0cywgYnV0IEkgY291
bGRu4oCZdCBmaW5kIHN1Y2ggZGVmaW5pdGlvbiBpbiBSRkM3NjM2Li4uPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDtUaGUgY2xpZW50IHdpbGwgc2VuZCB0aGUgY29k
ZSwgYWxvbmcgd2l0aCBhIChub3cgbm90IG1hdGNoaW5nKSBjb2RlX3ZlcmlmaWVyIHRvIHRoZSBz
ZXJ2ZXIuIFRoZSBzZXJ2ZXIgd2lsbCBpZ25vcmUgdGhlIGNvZGVfdmVyaWZpZXIgKGFzIGl0IHdh
cyBub3QgZXhwZWN0ZWQpIGFuZCBzZW5kIGJhY2sgYW4gYWNjZXNzIHRva2VuIGFuZCBJRCB0b2tl
biB0byB0aGUgY2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYW5pZWxmZXR0LmRl
LzIwMjAvMDUvMTYvcGtjZS12cy1ub25jZS1lcXVpdmFsZW50LW9yLW5vdC8jbm9uY2Vwa2NlLXNp
ZGVzdGVwLWF0dGFjayIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGFuaWVsZmV0dC5kZS8yMDIw
LzA1LzE2L3BrY2UtdnMtbm9uY2UtZXF1aXZhbGVudC1vci1ub3QvI25vbmNlcGtjZS1zaWRlc3Rl
cC1hdHRhY2s8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgYmVo
YXZpb3IgaXMgYWNjZXB0YWJsZSBieSBSRkM3NjM2LCAmcXVvdDtOb25jZS9QS0NFIFNpZGVzdGVw
IEF0dGFja+KAnSB3b3VsZCBiZSBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5JICp0aGluayogdGhhdCB0aGVyZSBpcyBub3RoaW5nIHByZXZlbnRpbmcgc2VydmVy
cyBmcm9tIHNvbWV0aW1lcyB1c2luZyBQS0NFIGFuZCBzb21ldGltZXMgdXNpbmcgTm9uY2UuIEkg
YXNzdW1lIHRoYXQgdGhpcyBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoZSBleGlzdGluZyBzcGVj
aWZpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J
IHdvdWxkIGJlIGludGVyZXN0ZWQgdG8gaGVhciBob3cgYWN0dWFsIGltcGxlbWVudGF0aW9ucyBo
YW5kbGUgdGhpcyBpbiBwcmFjdGljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlBsdXMsIHdpdGggc3VjaCBBUyBiZWhhdmlvciwgQ1NSRiBwcm90ZWN0aW9uIHVzaW5nIFBLQ0Ug
Y2FuIGFsc28gYmUgYnlwYXNzZWQgYXMgYmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBUaGUgYXR0YWNrZXIg
cmVtb3ZlcyBjb2RlX2NoYWxsZW5nZSBmcm9tIGhpcy9oZXIgb3duIEF1dGhaIFJlcSwmbmJzcDty
ZWNlaXZlcyZuYnNwO2Egbm9uLWNvZGVfY2hhbGxlbmdlLWJvdW5kIGNvZGUsIGFuZCBzZW5kcyBp
dCB0byB0aGUgdmljdGltLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVGhlIGNsaWVudCByZWNlaXZlcyB0aGUgYXR0
YWNrZXLigJlzIGNvZGUgZnJvbSB0aGUgdmljdGltLCBhbmQgc2VuZHMgaXQgdG8gdGhlIEFTIHcv
IHRoZSB2YWxpZCBjb2RlX3ZlcmlmaWVyIGJvdW5kIHRvIHRoZSB2aWN0aW3igJlzIGJyb3dzZXIg
c2Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjMuIFRoZSBBUyBpZ25vcmVzIHRoZSBjb2RlX3ZlcmlmaWVyIGFu
ZCByZXR1cm5zIHRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhhdOKAmXMg
dGhlIGNhc2UsIGN1cnJlbnQgT0F1dGggMi4wIFBLQ0UgaW1wbGVtZW50YXRpb24gY2FuIGJlIHdl
YWtlciB0aGFuIGV4cGVjdGVkLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RXhjZWxsZW50
IHBvaW50ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldvdWxk
IGl0IGJlIG9rYXkgaWYgSSBhZGQgdGhhdCBhdHRhY2sgdG8gdGhlIG9yaWdpbmFsIHBvc3QgKHdp
dGggY3JlZGl0cywgb2YgY291cnNlKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj4tRGFuaWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3Y8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
MjAyMC8wNS8xOSAxOjU0PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx
dW90OyI+44CBPC9zcGFuPkRhbmllbCBGZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZmV0dEBkYW5p
ZWxmZXR0LmRlIiB0YXJnZXQ9Il9ibGFuayI+ZmV0dEBkYW5pZWxmZXR0LmRlPC9hPiZndDs8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jga7jg6Hjg7zjg6s8
L3NwYW4+OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGFsa2luZyB0byBUb3JzdGVuLCB3ZSByZWFsaXplZCB0aGF0IHByb3ZpZGlu
ZyBhIGdlbmVyaWMgZXh0ZW5zaW9uIHBvaW50IGhlcmUgaXMgcHJvYmFibHkgbm90IGEgZ29vZCBp
ZGVhLiBJdCBpcyByZWFsbHkgaGFyZCB0byB0ZWxsIHdoYXQgcHJvdGVjdHMgeW91IGZyb20gY29k
ZSBpbmplY3Rpb24gYW5kIHdoYXQgZG9lcyBub3QsIGFuZCBwZW9wbGUgbWlnaHQgY29tZSB1cCB3
aXRoIGFsbCBzb3J0cyBvZiBub24tc3RhbmRhcmQNCiBhbmQgcG90ZW50aWFsbHkgaW5zZWN1cmUg
c29sdXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIGp1c3QgZm9y
IFBLQ0UgdnMuIE5vbmNlLCBpdCBpcyBub3Qgb2J2aW91cyBpZiB0aGV5IHByb3ZpZGUgdGhlIHNh
bWUgbGV2ZWwgb2YgcHJvdGVjdGlvbi4gSW4gYW4gYXR0ZW1wdCB0byBhbnN3ZXIgdGhpcyBxdWVz
dGlvbiwgSSB0cmllZCB0byBjb21lIHVwIHdpdGggYSBtb3JlIHN5c3RlbWF0aWMgYW5hbHlzaXMg
b2YgJnF1b3Q7UEtDRSB2cyBOb25jZSZxdW90Oy4gSSB3cm90ZSB1cCBteSByZXN1bHRzIGhlcmU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhbmllbGZldHQuZGUvMjAyMC8wNS8xNi9wa2Nl
LXZzLW5vbmNlLWVxdWl2YWxlbnQtb3Itbm90LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGFu
aWVsZmV0dC5kZS8yMDIwLzA1LzE2L3BrY2UtdnMtbm9uY2UtZXF1aXZhbGVudC1vci1ub3QvPC9h
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnI+DQpBbHRob3VnaCB0aGlzIGlzIG5vdCBhIGZvcm1hbCBhbmFseXNpcywgSSBob3Bl
IHRoYXQgSSBoYXZlIGNvdmVyZWQgYWxsIGludGVyZXN0aW5nIGNhc2VzLiBQbGVhc2UgcmV2aWV3
IHRoZSB0ZXh0IGFuZCBsZXQgbWUga25vdyBpZiBJIGhhdmUgbWlzc2VkIHNvbWV0aGluZyBvciBp
ZiB0aGVyZSBhcmUgYW55IG1pc3Rha2VzLjxicj4NCjxicj4NClRoZSBtYWluIHJlc3VsdHMgYXJl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFy
dD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omww
IGxldmVsMSBsZm8xIj5JbiB0ZXJtcyBvZiBwcm90ZWN0aW9uIGFnYWluc3QgQ1NSRiBhbmQgY29k
ZSBtaXN1c2UsIFBLQ0UgYW5kIE5vbmNlIHByb3ZpZGUgc2ltaWxhciBsZXZlbHMgb2Ygc2VjdXJp
dHksIHdpdGggYSBzbGlnaHQgYWR2YW50YWdlIGZvciBQS0NFLjxvOnA+PC9vOnA+PC9saT48bGkg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JbiBwcmFj
dGljZSwgYSBjaXJjdW12ZW50aW9uIG9mIGJvdGggbWVjaGFuaXNtcywgaG93ZXZlciwgaXMgcG9z
c2libGUgaWYgYW4gQVMgYWxsb3dzIGEgY2xpZW50IHRvIGNob29zZSBiZXR3ZWVuIFBLQ0UgYW5k
IE5vbmNlIGFuZCB0aGUgY2xpZW50IG1ha2VzIHVzZSBvZiB0aGlzIGZyZWVkb20uIEkgcHJvcG9z
ZSB0byBjYWxsIHRoaXMgYXR0YWNrIHRoZQ0KIE5vbmNlL1BLQ0UgU2lkZXN0ZXAgQXR0YWNrLiDi
hpIgUGxlYXNlIHJldmlldyB0aGUgYXR0YWNrIGRlc2NyaXB0aW9uIGluIHRoZSBhbmFseXNpcy48
bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBs
ZXZlbDEgbGZvMSI+VG8gYXZvaWQgdGhlIE5vbmNlL1BLQ0UgU2lkZXN0ZXAgQXR0YWNrLCBjbGll
bnRzIG11c3Qgbm90IHN3aXRjaCBiZXR3ZWVuIHVzaW5nIG9ubHkgUEtDRSBhbmQgb25seSBOb25j
ZSAoYnV0IG1heSB1c2UgYm90aCBpbiBwYXJhbGxlbCwgb3Igc3dpdGNoIGJldHdlZW4gdXNpbmcg
b25seSBQS0NFIGFuZCBQS0NFJiM0MztOb25jZSkuIEF1dGhvcml6YXRpb24gc2VydmVycw0KIG11
c3QgZW5mb3JjZSBQS0NFIHVubGVzcyB0aGV5IGtub3cgdGhhdCB0aGUgY2xpZW50IHVzZXMgTm9u
Y2UgZm9yIGFsbCBvZiBpdHMgZmxvd3MgKGFuZCBjaGVja3MgdGhlIE5vbmNlIHZhbHVlKS4gVGhl
IHByZXNlbmNlIG9mIGEgbm9uY2UgcGFyYW1ldGVyIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVl
c3QgaXMgbm90IHN1ZmZpY2llbnQgdG8gZGV0ZXJtaW5lIGlmIGEgY2xpZW50IGFjdHVhbGx5IGNo
ZWNrcyB0aGUgbm9uY2UgY2xhaW0gaW4gdGhlDQogSUQgdG9rZW4uPG86cD48L286cD48L2xpPjwv
b2w+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgeW91IGNhbiBzZWUsIGFscmVhZHkg
aGF2aW5nIHR3byBtb3JlLW9yLWxlc3Mgd2VsbC11bmRlcnN0b29kIG1lY2hhbmlzbXMgaXMgaGFy
ZCBlbm91Z2ggdG8gd3JhcCB5b3VyIGhlYWQgYXJvdW5kIGZyb20gYSBzZWN1cml0eSBzdGFuZHBv
aW50LiBXZSBzaG91bGQgdGhlcmVmb3JlIG1ha2UgUEtDRSB0aGUgZGVmYXVsdCBhbmQgTm9uY2Ug
YW4gb3B0aW9uIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHRoaXMgZW5kLCBJIHdvdWxkIGxp
a2UgdG8gcHJvcG9zZSB0aGUgZm9sbHdpbmcgc3RyYXdtYW4sIGJhc2VkIG9uIFRvcnN0ZW4ncyBh
bmQgQWFyb24ncyBzdWdnZXN0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QW4g
QVMgTVVTVCByZWplY3QgcmVxdWVzdHMgd2l0aG91dCBhIGNvZGVfY2hhbGxlbmdlIGZyb20gcHVi
bGljPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD5jbGllbnRzLCBhbmQgTVVTVCByZWpl
Y3Qgc3VjaCByZXF1ZXN0cyBmcm9tIG90aGVyIGNsaWVudHMgdW5sZXNzIHRoZXJlPC90dD48YnI+
DQo8dHQ+aXMgcmVhc29uYWJsZSBhc3N1cmFuY2UgdGhhdCB0aGUgY2xpZW50IG1pdGlnYXRlcyBh
dXRob3JpemF0aW9uIGNvZGU8L3R0Pjxicj4NCjx0dD5pbmplY3Rpb24gdXNpbmcgdGhlIE9wZW5J
RCBDb25uZWN0IE5vbmNlIG1lY2hhbmlzbSBhbmQgdGhhdCB0aGlzPC90dD48YnI+DQo8dHQ+bWl0
aWdhdGlvbiBpcyB1c2VkIGZvciBhbGwgaW50ZXJhY3Rpb25zIHdpdGggdGhlIGNsaWVudC4gU2Vl
IHNlY3Rpb248L3R0Pjxicj4NCjx0dD45LjcgZm9yIGRldGFpbHMuPC90dD48L3NwYW4+PGJyPg0K
PGJyPg0KU2VjdGlvbiA5Ljc6PGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij5DbGllbnRzIE1VU1QgcHJldmVudCBpbmplY3Rpb24gKHJlcGxheSkgb2YgYXV0aG9y
aXphdGlvbiBjb2RlcyBpbnRvPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD50aGUgYXV0
aG9yaXphdGlvbiByZXNwb25zZSBieSBhdHRhY2tlcnMuIFRoZSB1c2Ugb2YgdGhlPC90dD48YnI+
DQo8dHQ+YGNvZGVfY2hhbGxlbmdlYCBwYXJhbWV0ZXIgaXMgUkVDT01NRU5ERUQgdG8gdGhpcyBl
bmQuIEZvcjwvdHQ+PGJyPg0KPHR0PmNvbmZpZGVudGlhbCBjbGllbnRzLCB0aGUgT3BlbklEIENv
bm5lY3QgYG5vbmNlYCBwYXJhbWV0ZXIgYW5kIElEPC90dD48YnI+DQo8dHQ+VG9rZW4gQ2xhaW0g
e3tPcGVuSUR9fSBNQVkgYmUgdXNlZCBpbnN0ZWFkIG9mIG9yIGluIGFkZGl0aW9uIHRvIHRoZTwv
dHQ+PGJyPg0KPHR0PmBjb2RlX2NoYWxsZW5nZWAgcGFyYW1ldGVyIGZvciB0aGlzIHB1cnBvc2Uu
IFRoZSBgY29kZV9jaGFsbGVuZ2VgIG9yPC90dD48YnI+DQo8dHQ+T3BlbklEIENvbm5lY3QgYG5v
bmNlYCB2YWx1ZSBNVVNUIGJlIHRyYW5zYWN0aW9uLXNwZWNpZmljIGFuZCBzZWN1cmVseTwvdHQ+
PGJyPg0KPHR0PmJvdW5kIHRvIHRoZSBjbGllbnQgYW5kIHRoZSB1c2VyIGFnZW50IGluIHdoaWNo
IHRoZSB0cmFuc2FjdGlvbiB3YXM8L3R0Pjxicj4NCjx0dD5zdGFydGVkLjwvdHQ+PGJyPg0KPGJy
Pg0KPHR0PklmIHRoZSBPcGVuSUQgQ29ubmVjdCBgbm9uY2VgIGlzIHVzZWQgdG8gbWl0aWdhdGUg
YXV0aG9yaXphdGlvbiBjb2RlPC90dD48YnI+DQo8dHQ+aW5qZWN0aW9uIGluc3RlYWQgb2YgYGNv
ZGVfY2hhbGxlbmdlYCwgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlcjwvdHQ+PGJyPg0K
PHR0Pk1VU1QgZW5zdXJlIHRoYXQgdGhlIG1pdGlnYXRpb24gaXMgYXBwbGllZCB0byBldmVyeSBp
bnRlcmFjdGlvbiB3aXRoPC90dD48YnI+DQo8dHQ+dGhlIGNsaWVudCBhbmQgdGhhdCB0aGUgY2xp
ZW50IGNhbm5vdCBzd2l0Y2ggYmV0d2VlbiBgY29kZV9jaGFsbGVuZ2VgPC90dD48YnI+DQo8dHQ+
YW5kIGBub25jZWAuIEZvciBleGFtcGxlLCB0aGUgcHJlc2VuY2Ugb2YgYSBgbm9uY2VgIHBhcmFt
ZXRlciBpbiB0aGU8L3R0Pjxicj4NCjx0dD5hdXRob3JpemF0aW9uIHJlcXVlc3QgaXMgbm90IHN1
ZmZpY2llbnQgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlPC90dD48YnI+DQo8dHQ+YGNvZGVfdmVyaWZp
ZXJgIGNoZWNrIGNhbiBiZSBza2lwcGVkLjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UsIHdlIG5lZWQgdG8g
YWRhcHQgdGhlIHdvcmRpbmcgaW4gdGhlIFNlY3VyaXR5IEJDUCBhY2NvcmRpbmdseS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1EYW5pZWw8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QW0gMTUuMDUuMjAgdW0gMDE6MDEgc2NocmllYiBNaWtlIEpvbmVz
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5JIGFncmVlIHdpdGggTm92
IHRoYXQgb2JzY3VyaW5nIHRoZSBsYW5ndWFnZSBpbiA5Ljcgd291bGQgYmUgYSBkaXNzZXJ2aWNl
IHRvIGRldmVsb3BlcnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48
L3ByZT4NCjxwcmU+VGhlIFNlY3VyaXR5IEJDUCwgd2hpY2ggaGFzIGFscmVhZHkgZ29pbmcgdGhl
IFdHTEMsIGV4cGxpY2l0bHkgY2FsbHMgb3V0IHRoZSB1c2Ugb2Ygbm9uY2UgYXMgcGFydCBvZiB0
aGUgYmVzdCBwcmFjdGljZXMuJm5ic3A7IE9BdXRoIDIuMSBzaG91bGQgZG8gbm8gbGVzcy48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgOS43
IGxhbmd1YWdlIHRoYXQgQWFyb24gcHJvcG9zZWQgd2FzIHRoZSByZXN1bHQgb2YgbWFueSBwZW9w
bGUncyBjb250cmlidXRpb25zIGFuZCBhIHZpZ29yb3VzIGRpc2N1c3Npb24uJm5ic3A7IExldCdz
IHB1Ymxpc2ggdGhlIG5leHQgdmVyc2lvbiBvZiAyLjEgd2l0aCB0aGF0IGxhbmd1YWdlIGludGFj
dCwgYXMgSSBiZWxpZXZlIGl0IHJlcHJlc2VudHMgYXQgbGVhc3QgYSBsb2NhbCBwb2ludCBvZiBo
YXJkLXdvbiBjb25zZW5zdXMuJm5ic3A7IExldCdzIGdldCB0aGF0IGxhbmd1YWdlIGludG8gdGhl
IHJlY29yZCBvZiBkcmFmdHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286
cD48L3ByZT4NCjxwcmU+VGhlcmUncyBhbHdheXMgdGltZSB0byBkZWJhdGUgaXQgYW5kIGNoYW5n
ZSBpdCBsYXRlciBpbiBzdWJzZXF1ZW50IGRyYWZ0cywgYnV0IGxldCdzIG5vdCBub3cgbG9zZSB3
aGF0IGl0IHRvb2sgYSBsb3Qgb2YgZWZmb3J0IHRvIGFjaGlldmUuPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo
YW5rcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogTm92IE1h
dGFrZSA8YSBocmVmPSJtYWlsdG86bWF0YWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZs
dDttYXRha2VAZ21haWwuY29tJmd0OzwvYT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDog
VGh1cnNkYXksIE1heSAxNCwgMjAyMCAzOjE4IEFNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86
IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu
bmV0IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OzwvYT48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzogT0F1dGggV0cgPGEgaHJlZj0ibWFpbHRvOm9hdXRo
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT47IE1p
a2UgSm9uZXMgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHByb3Bvc2VkIHJlc29s
dXRpb24gZm9yIFBLQ0UgaW4gT0F1dGggMi4xPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlcmUgaXMgbm8gc3BlY2lmaWMgbWVjaGFuaXNtIHJp
Z2h0IG5vdy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CdXQgZnV0dXJlIGRldmVsb3BlcnMgd29u
4oCZdCBiZSBhYmxlIHRvIHJlYWQgdGhlIHJlYXNvbiB3aHkgdGhlIGV4dGVuc2lvbiBwb2ludCBp
cyBnaXZlbiBvbmx5IGZvciBjb25maWRlbnRpYWwgY2xpZW50cy48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPk9uIE1heSAxNCwgMjAyMCwgYXQg
MTg6MzIsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVy
c3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0
OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+QXJlIHlvdSBhd2FyZSBvZiBhbnkgc3VpdGFibGUgbWVjaGFuaXNtPyBJ4oCZbSBh
c2tpbmcgc2luY2UgZnJvbSBteSBwZXJzcGVjdGl2ZSB0aGlzIGNsYXVzZSBpcyBtYWlubHkgaW50
ZW5kZWQgdG8gYWxsb3cgZXhpc3RpbmcgT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHMgdG8gdXNl
IG5vbmNlIGluc3RlYWQgb2YgUEtDRSBpbiBjb21iaW5hdGlvbiB3aXRoIE9BdXRoIDIuMS4gSXTi
gJlzIGEgY29tcHJvbWlzZS4gSSB0aGluayB3ZSBzaG91bGQgbm90IGVuY291cmFnZSBvdGhlcnMg
dG8gaW52ZW50IHRoZWlyIG93biBPQXV0aCBzZWN1cml0eSBtZWNoYW5pc21zLiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPk9uIDE0LiBNYXkg
MjAyMCwgYXQgMDk6MzcsIE5vdiBNYXRha2UgPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBnbWFpbC5j
b20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7bWF0YWtlQGdtYWlsLmNvbSZndDs8L2E+IHdyb3RlOjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhpLDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldoeSBu
b3QgYWxsb3dpbmcgcHVibGljIGNsaWVudHMgdXNlICZxdW90O290aGVyIHN1aXRhYmxlIG1lY2hh
bmlzbXPigJ0gdGhlbj88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBXRyBjYW4gYWxsb3cg
Ym90aCB0eXBlIG9mIGNsaWVudHMgZG8gc28sIHRoZW4gT0lERiB3aWxsIGRlZmluZSBub25jZSBh
cyB0aGUgYWx0ZXJuYXRpdmUgb25seSBmb3IgY29uZmlkZW50aWFsIGNsaWVudHMuPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4yMDIwLzA1LzE0
IDE1OjU2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44CB
PC9zcGFuPlRvcnN0ZW4gTG9kZGVyc3RlZHQgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW49NDBsb2Rk
ZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4mbHQ7dG9yc3Rlbj00
MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZyZndDs8L2E+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44Gu44Oh44O844OrPC9zcGFuPjo8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IaSBhbGwsPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SSB3b3Vs
ZCBhbHNvIGxpa2UgdG8gdGhhbmsgZXZlcnlib2R5IGZvciB0aGUgc3Vic3RhbnRpYWwgZGlzY3Vz
c2lvbi4mbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+VGhlIHByb3Bvc2VkIGNoYW5nZSBmb3IgU2VjdGlvbiA0LjEuMi4xIHdvcmtzIGZv
ciBtZSAoYXMgYWxyZWFkeSBzdGF0ZWQpLiBJ4oCZbSBub3QgZnVsbHkgY29tZm9ydGFibGUgd2l0
aCB0aGUgcHJvcG9zZWQgY2hhbmdlIGZvciBTZWN0aW9uIDkuNyBmb3IgdGhlIGZvbGxvd2luZyBy
ZWFzb25zOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPi0gVGhlIHRleHQgaXMgd2Vha2VyIHRoYW4gU2VjdGlvbiA0LjEuMi4xIHNpbmNlIGl0IFJF
Q09NTUVORFMgdXNlIG9mIFBLQ0UgaW5zdGVhZCBvZiByZXF1aXJpbmcgaXQgKHdpdGggYSB3ZWxs
LWRlZmluZWQgZXhjZXB0aW9uKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIEdpdmVuIHRoZSBs
YXRlc3QgZmluZGluZ3MgcmUgbm9uY2UgSSBkb27igJl0IGZlZWwgY29tZm9ydGFibGUgd2l0aCBy
ZWNvbW1lbmRpbmcgYW55IG1lY2hhbmlzbSB0aGF0IHRoaXMgV0cgaXMgbm90IHJlc3BvbnNpYmxl
IGZvciBhbmQgdGh1cyBkaWQgbm90IGNvbmR1Y3QgdGhlIHNlY3VyaXR5IHRocmVhdCBhbmFseXNp
cyBmb3IuIEkgdGhpbmsgdGhlIGJldHRlciB3YXkgZm9yIHVzIGFzIFdHIGlzIHRvIGRlZmluZSB0
aGUgZXh0ZW5zaW9uIHBvaW50IGZvciBvdGhlciBtZWNoYW5pc21zLiBUaGUgT3BlbklEIEZvdW5k
YXRpb24gKG9yIGFueSBvdGhlciBib2R5KSBjYW4gdGhlbiBmaWxsIGluIGFuZCBpc3N1ZSBhIHN0
YXRlbWVudCB0aGF0IG5vbmNlIChvciBhbm90aGVyIHN1aXRhYmxlIG1lY2hhbmlzbSkgZnVsZmls
cyB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBleHRlbnNpb24gcG9pbnQuIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJhc2VkIG9uIHRoaXMgY29u
c2lkZXJhdGlvbnMsIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgZm9yIFNlY3Rpb24gOS43
OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNs
aWVudHMgTVVTVCBwcmV2ZW50IGluamVjdGlvbiAocmVwbGF5KSBvZiBhdXRob3JpemF0aW9uIGNv
ZGVzIGludG8gPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIGF1dGhvcml6YXRpb24gcmVzcG9u
c2UgYnkgYXR0YWNrZXJzLiBQdWJsaWMgY2xpZW50cyBNVVNUIHVzZSB0aGUgPG86cD48L286cD48
L3ByZT4NCjxwcmU+JnF1b3Q7Y29kZV9jaGFsbGVuZ2XigJ0gd2l0aCBhIHRyYW5zYWN0aW9uLXNw
ZWNpZmljIHZhbHVlIHRoYXQgaXMgc2VjdXJlbHkgPG86cD48L286cD48L3ByZT4NCjxwcmU+Ym91
bmQgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVzZXIgYWdlbnQgaW4gd2hpY2ggdGhlIHRyYW5zYWN0
aW9uIHdhcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdGFydGVkLiBDb25maWRlbnRpYWwgY2xp
ZW50cyBNVVNUIHVzZSB0aGUg4oCcY29kZV9jaGFsbGVuZ2XigJ0gaW4gdGhlIDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPnNhbWUgd2F5IG9yIG90aGVyIHN1aXRhYmxlIG1lY2hhbmlzbXMgdG8gbWl0
aWdhdGUgYXV0aG9yaXphdGlvbiBjb2RlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluamVjdGlv
bi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5U
aGlzIHRleHQgZm9sbG93cyB0aGUgbG9naWMgaW4gU2VjdGlvbiA0LjEuMi4xIGFuZCBhbGxvd3Mg
dXNlIG9mIHRoZSBub25jZSBmb3IgY29uZmlkZW50aWFsIGNsaWVudHMuPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YmVzdCByZWdhcmRzLDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlRvcnN0ZW4uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OzxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+T24gMTIuIE1heSAyMDIwLCBhdCAwMjoyMSwgTWlr
ZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1h
cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4mbHQ7TWljaGFlbC5Kb25lcz00MG1pY3Jvc29m
dC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGF0IHdvcmtzIGZvciBtZS4mbmJzcDsg
VGhhbmtzIGFsbCBmb3IgdGhlIHVzZWZ1bCBiYWNrLWFuZC1mb3J0aCB0aGF0IGdvdCB1cyB0byB0
aGlzIHBvaW50IG9mIGNsYXJpdHkuJm5ic3A7IEkgc3VzcGVjdCBtYW55IG9mIHVzIGxlYXJuZWQg
dGhpbmdzIGFsb25nIHRoZSB3YXk7IEkga25vdyB0aGF0IEkgZGlkITxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBDaGVlcnMsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t
IE1pa2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5Gcm9tOiBBYXJvbiBQYXJlY2tpIDxhIGhyZWY9Im1haWx0bzphYXJvbkBwYXJlY2tpLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPiZsdDthYXJvbkBwYXJlY2tpLmNvbSZndDs8L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmU+U2VudDogTW9uZGF5LCBNYXkgMTEsIDIwMjAgNDo1NSBQTTxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPlRvOiBPQXV0aCBXRyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkNjOiBOZWlsIE1hZGRlbiA8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRkZW5AZm9y
Z2Vyb2NrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29t
Jmd0OzwvYT47IE1pa2UgSm9uZXMgPG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFp
bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtNaWNo
YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1
YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHByb3Bvc2VkIHJlc29sdXRpb24gZm9yIFBLQ0UgaW4gT0F1
dGggMi4xPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmU+VGhhbmsgeW91IE5laWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286
cD48L3ByZT4NCjxwcmU+VG8gYWRkcmVzcyBNaWtlJ3MgY29uY2VybnMgaW4gdGhlIHByZXZpb3Vz
IHRocmVhZHMsIEkgd291bGQgbGlrZSB0byBhbHNvIHVwZGF0ZSBzZWN0aW9uIDkuNyB3aXRoIHRo
ZSBmb2xsb3dpbmcgdGV4dDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5DbGllbnRzIE1VU1QgcHJldmVudCBpbmplY3Rpb24gKHJlcGxheSkgb2Yg
YXV0aG9yaXphdGlvbiBjb2RlcyBpbnRvIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBhdXRo
b3JpemF0aW9uIHJlc3BvbnNlIGJ5IGF0dGFja2Vycy4gVGhlIHVzZSBvZiB0aGUgPG86cD48L286
cD48L3ByZT4NCjxwcmU+YGNvZGVfY2hhbGxlbmdlYCBwYXJhbWV0ZXIgaXMgUkVDT01NRU5ERUQg
dG8gdGhpcyBlbmQuIEZvciA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb25maWRlbnRpYWwgY2xp
ZW50cywgdGhlIE9wZW5JRCBDb25uZWN0IGBub25jZWAgcGFyYW1ldGVyIGFuZCBJRCA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5Ub2tlbiBDbGFpbSB7e09wZW5JRH19IE1BWSBiZSB1c2VkIGluc3Rl
YWQgb2Ygb3IgaW4gYWRkaXRpb24gdG8gdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmBjb2Rl
X2NoYWxsZW5nZWAgcGFyYW1ldGVyIGZvciB0aGlzIHB1cnBvc2UuIFRoZSBgY29kZV9jaGFsbGVu
Z2VgIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9yIE9wZW5JRCBDb25uZWN0IGBub25jZWAgdmFs
dWUgTVVTVCBiZSB0cmFuc2FjdGlvbi1zcGVjaWZpYyBhbmQgPG86cD48L286cD48L3ByZT4NCjxw
cmU+c2VjdXJlbHkgYm91bmQgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVzZXIgYWdlbnQgaW4gd2hp
Y2ggdGhlIHRyYW5zYWN0aW9uIHdhcyBzdGFydGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgY2hhbmdlIGJldHRlciBjbGFyaWZpZXMg
dGhlIHNwZWNpZmljIGNpcmN1bXN0YW5jZXMgdW5kZXIgd2hpY2ggdGhlICZxdW90O25vbmNlJnF1
b3Q7IHBhcmFtZXRlciBpcyBzdWZmaWNpZW50IHRvIHByb3RlY3QgYWdhaW5zdCBhdXRob3JpemF0
aW9uIGNvZGUgaW5qZWN0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkFhcm9uIFBhcmVja2k8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PbiBNb24sIE1heSAxMSwgMjAyMCBhdCAxMTo1NSBB
TSBOZWlsIE1hZGRlbiA8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPiZsdDtuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tJmd0OzwvYT4gd3Jv
dGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+SSBhbSBoYXBweSB3aXRoIHRoaXMgcHJvcG9zZWQg
d29yZGluZy4gVGhhbmtzIGZvciB1cGRhdGluZyBpdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7igJQgTmVpbDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPk9uIDExIE1heSAyMDIwLCBhdCAxOTo1MiwgQWFyb24gUGFyZWNraSA8YSBocmVmPSJt
YWlsdG86YWFyb25AcGFyZWNraS5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7YWFyb25AcGFyZWNr
aS5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5UaGFua3MgZm9yIHRoZSBsaXZlbHkgZGlzY3Vzc2lvbiBhcm91bmQg
UEtDRSBpbiBPQXV0aCAyLjEgZXZlcnlvbmUhIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldlIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9s
bG93aW5nIHRleHQsIHdoaWNoIGlzIGEgc2xpZ2h0IHZhcmlhdGlvbiBmcm9tIHRoZSB0ZXh0IE5l
aWwgcHJvcG9zZWQuIFRoaXMgd291bGQgcmVwbGFjZSB0aGUgcGFyYWdyYXBoIGluIDQuMS4yLjEg
KDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXJlY2tpLW9hdXRo
LXYyLTEtMDIjc2VjdGlvbi00LjEuMi4xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LXBhcmVja2ktb2F1dGgtdjItMS0wMiNzZWN0aW9uLTQuMS4yLjE8
L2E+KSB0aGF0IGJlZ2lucyB3aXRoICZxdW90O0lmIHRoZSBjbGllbnQgZG9lcyBub3Qgc2VuZCB0
aGUgJnF1b3Q7Y29kZV9jaGFsbGVuZ2UmcXVvdDsgaW4gdGhlIHJlcXVlc3QuLi4mcXVvdDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mcXVvdDtB
biBBUyBNVVNUIHJlamVjdCByZXF1ZXN0cyB3aXRob3V0IGEgY29kZV9jaGFsbGVuZ2UgZnJvbSBw
dWJsaWMgY2xpZW50cywgYW5kIE1VU1QgcmVqZWN0IHN1Y2ggcmVxdWVzdHMgZnJvbSBvdGhlciBj
bGllbnRzIHVubGVzcyB0aGVyZSBpcyByZWFzb25hYmxlIGFzc3VyYW5jZSB0aGF0IHRoZSBjbGll
bnQgbWl0aWdhdGVzIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gaW4gb3RoZXIgd2F5cy4u
IFNlZSBzZWN0aW9uIDkuNyBmb3IgZGV0YWlscy4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZWN0aW9uIDkuNyBpcyB3aGVyZSB0aGUg
bnVhbmNlcyBvZiBQS0NFIHZzIG5vbmNlIGFyZSBkZXNjcmliZWQuPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgTmVpbCBkZXNjcmliZWQsIHdl
IGJlbGlldmUgdGhpcyB3aWxsIGFsbG93IEFTcyB0byBzdXBwb3J0IGJvdGggT0F1dGggMi4wIGFu
ZCAyLjEgY2xpZW50cyBzaW11bHRhbmVvdXNseS4gVGhlIGNoYW5nZSBmcm9tIE5laWwncyB0ZXh0
IGlzIHRoZSBjbGFyaWZpY2F0aW9uIG9mIHdoaWNoIHRocmVhdHMsIGFuZCBjaGFuZ2luZyB0byBN
VVNUIGluc3RlYWQgb2YgU0hPVUxELiBUaGUgJnF1b3Q7TVVTVC4uLnVubGVzcyZxdW90OyBpcyBt
b3JlIHNwZWNpZmljIHRoYW4gJnF1b3Q7U0hPVUxEJnF1b3Q7LCBhbmQgc2luY2Ugd2UgYXJlIGFs
cmVhZHkgZGVzY3JpYmluZyB0aGUgZXhwbGljaXQgZXhjZXB0aW9uIHRvIHRoZSBydWxlLCBpdCdz
IG1vcmUgY2xlYXIgYXMgYSBNVVNUIGhlcmUuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmU+QWFyb24gUGFyZWNraTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3By
ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5P
QXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHBy
ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N
CjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i
bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_DM6PR00MB0684E59FE5A75B15E1C432C6F5B60DM6PR00MB0684namp_--


From nobody Wed May 20 20:43:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284743A0A6E for ; Wed, 20 May 2020 20:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcXC14ru_mvj for ; Wed, 20 May 2020 20:43:22 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::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 A8D593A0A6C for ; Wed, 20 May 2020 20:43:22 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id r25so5097913oij.4 for ; Wed, 20 May 2020 20:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language; bh=JAsv7mchq8UlAMFjwFuD1ACC9ybfXOdqbqR+uj59zkU=; b=P4z0fNi+evHn15jgU7Rj9uCvI9w2pYCwR4TaRLT/a1cldZtk69HfZDfLLrdvaNrN7i 0x2As83K/nP1vx88lI8cIvRaEdWi+CWNmulJX+jsJXa0tWenX6CrmEpFQw+kj+Es2Krg jT9FnPh1nBsY4LmM6o3PeU0oKf1VvlpKqZDTQqJTbzsP+xONa1oy7wr9EhFrhlVgc0l7 CMrQkYd5NfWNzy8c+FyBzGUw4a01T7XobBHUhaAh/JGnk+ausojDdVGIFYuHBYt5LaaW M7hot6ADMCH39EUxyHpeiuZU88iMBywf2jsvxfcJyl1lQ120cPi96EWfKXRDUojXDaxK JLmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language; bh=JAsv7mchq8UlAMFjwFuD1ACC9ybfXOdqbqR+uj59zkU=; b=BVXU+4gf1GepqkNt1io7BpkBUT4LQB3gLkzRS6VVuNtasfC1YRgWxSwACUJNN5C7L4 CAkp3qSLYUduNcG8beG3QRb7lGdZFarsDbdAjwC+9qnU3UzyhLp0JqyL1zdajWobHrvk RSXMG4jg/QLAybYONsrufnC1lo1UQYIuEU2SU4g2Xwwd4IXA3+8FEeH+sHpJkfwKHgp/ pILF65zRDRYAMjii0Etohcith4GhiSPubv9gVWB+iq/0vRRl78fLypL2pt4zxVW+Tvf6 eYSYW60mU42ZgEtHfPzgf9vAmOU8WEid+GXkX22rsmCQH4oElOlyiJ3aWbB74xZdy1tl CHTw==
X-Gm-Message-State: AOAM532aUP6CjNtQIc405/8cElnPK4golN5znkZWOfesNgWWix0PKPv2 SleFjbEHEYw2j3t0FCKoBMnSfwFsQic=
X-Google-Smtp-Source: ABdhPJwIsVQFj30O3ia4qme43Q9BZ/MG8LiPf7Y7JAUeBPjMkNLo6IvC3yx8+lGgNtPLCkUWYHJamQ==
X-Received: by 2002:aca:cdc6:: with SMTP id d189mr5740391oig.19.1590032601158;  Wed, 20 May 2020 20:43:21 -0700 (PDT)
Received: from jareds-mbp-2.lan ([72.214.170.165]) by smtp.gmail.com with ESMTPSA id g30sm1343966oiy.42.2020.05.20.20.43.19 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 20:43:20 -0700 (PDT)
To: oauth 
From: Jared L Jennings 
Organization: Ninja Tools
Message-ID: 
Date: Wed, 20 May 2020 22:43:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------0CC581FCD4977ED7A9C2438E"
Content-Language: en-US
Archived-At: 
Subject: [OAUTH-WG] Questions about oauth-browser-based-apps-06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 May 2020 03:43:24 -0000

This is a multi-part message in MIME format.
--------------0CC581FCD4977ED7A9C2438E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I'm surprised that this is OK. Why is this safe or a best practice?

    /The Application Server can store the access token either server-side, /
    /or in the cookie itself./


What are appropriate browser APIs? (Maybe providing some guidance or a 
hint regarding this?)

    /The JavaScript app is then responsible for storing the access token /
    /(and optional refresh token) securely using appropriate browser APIs./


Can the access token be included the various (all) available transport 
methods? Query string, Header, Post, etc.

/When the JavaScript application in the browser wants to make a request 
to the Resource Server, it can include the access token in the request 
(D) and make the request directly./


Thanks,

-- 
-----
Jared L Jennings
816.678.4152
Skype: jaredljennings


--------------0CC581FCD4977ED7A9C2438E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
I'm surprised that this
        is OK. Why is this safe or a best practice?

    

    
The Application Server can store the access token
        either server-side, 

      or in the cookie itself.

    

    


    

    
What are appropriate
        browser APIs? (Maybe providing some guidance or a hint regarding
        this?)

    
The JavaScript app is then responsible for storing
        the access token 

      (and optional refresh token) securely using appropriate browser
        APIs.

    

    

    Can the access token be
      included the various (all) available transport methods? Query
      string, Header, Post, etc.
    
   When the JavaScript application in the browser wants to make a
   request to the Resource Server, it can include the access token in
   the request (D) and make the request directly.


    


    

    Thanks,

    
-- 
-----
Jared L Jennings
816.678.4152
Skype: jaredljennings

  


--------------0CC581FCD4977ED7A9C2438E--


From nobody Thu May 21 13:07:47 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B588B3A074B for ; Thu, 21 May 2020 13:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAUkCXyTaJ0G for ; Thu, 21 May 2020 13:07:43 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741BD3A073D for ; Thu, 21 May 2020 13:07:42 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04LK7aE3009921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 May 2020 16:07:38 -0400
Date: Thu, 21 May 2020 13:07:35 -0700
From: Benjamin Kaduk 
To: Denis 
Cc: oauth@ietf.org, Vittorio Bertocci 
Message-ID: <20200521200735.GL58497@kduck.mit.edu>
References:  <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 May 2020 20:07:45 -0000

On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> 
> Since then, I questioned myself how a client would be able to request an 
> access token that would be
> *strictly compliant with this Profile*.

I don't understand why this is an interesting question to ask.  The access
token and interpretation thereof is (AIUI) generally seen as an internal
matter between AS and RS, with the client having no need to care about the
specifics.  To my knowledge, this WG has not previously given guidance
indicating that the client should be involved or specifics for how to do
so, and I do not remember seeing WG agreement that this should change.

-Ben


From nobody Thu May 21 23:10:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612303A0ED6 for ; Thu, 21 May 2020 23:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6nt_9eyNxPO for ; Thu, 21 May 2020 23:10:20 -0700 (PDT)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 5A0643A0ED5 for ; Thu, 21 May 2020 23:10:20 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id c0sqjBxjVdUjIc0ssj3erX; Thu, 21 May 2020 23:10:19 -0700
X-CMAE-Analysis: v=2.3 cv=V4wDLtvi c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=is3RsFX7AAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=xtERp6CFAAAA:8 a=aIV-FTHC-H4Dhrm39lYA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=UmaLIfN2AhQ9ysBL:21 a=JRyh2daJwUtBteVW:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=pGLkceISAAAA:8 a=-fURarvJKJOy_1CgWcQA:9 a=ToMOwuxt29NOrO82:21 a=1xyAgr1_yCD1nCmP:21 a=eyPr8bBxdJ_wKJy8:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=CvJ-9y_HEmGQg9NJmnFv:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Joseph Heenan 
Cc: Dave Tonge , oauth , Openid-specs-fapi 
References:  <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io>
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com>
Date: Fri, 22 May 2020 09:10:16 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070006080209000105010900"
X-CMAE-Envelope: MS4wfB6rIq50gKwPxYy84Lgu6k0kT5zB1Q3iYXGq3Fdn1qCbsFRGc7hPHzCPjwncwiA+/CYb7t6zZRooFmn2g9S9oPV8Gsr8EpUTUqN/hZ9XRrJXZBCxwNlh 0xwlltwrzyQ8gBcbpcn/qS4LRMfSYrpPJTFkNNRDTvk4cD22XgvwJICBHEo0LlxOq7X/V7cB61bIztcnM7iKZkS8Mx7PSS1gUWORpHzeB7L2dVN7xLrtiwsW 4TVxk7DmwGQGE3cuPX8XNiFgaYjlxyACQAXRgHcCEP4B9HEH9XVsjm5y+RrMVg5RH6ftT0x7nXDq9Ki2KAlB/w==
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 May 2020 06:10:23 -0000

This is a cryptographically signed message in MIME format.

--------------ms070006080209000105010900
Content-Type: multipart/alternative;
 boundary="------------15EEEA6A56145CD278395228"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------15EEEA6A56145CD278395228
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

A mapping like the one you propose can definitely work. Since the user
will be making the choice which endpoint to take with the client app,
having the logo_uri is a good idea. If the branded endpoints differ
somehow in policy one could also allow inclusion of the op_policy_uri
and op_tos_uri params from Discovery.

https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscover=
y

Vladimir

On 20/05/2020 19:16, Joseph Heenan wrote:
> Thanks for your thoughts Vladimir!
>
> The client_id based solution I wasn=E2=80=99t previously aware of -
> unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile
> OS selects the app to use based purely on the URL (and in at least the
> iOS case will not offer the user a choice if multiple apps claim to
> handle the same url).
>
> I think some kind of mapping like you suggest will work and fallback,
> I wonder about a structure in the authorization server metadata
> something like this:
>
> {
> =C2=A0 ...
> =C2=A0 "alternative_authorization_endpoints": [
> =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 "authorization_endpoint": "https://loadsamoney/bus=
iness/auth",
> =C2=A0 =C2=A0 =C2=A0 "description": "loadsmoney business banking custom=
ers",
> =C2=A0 =C2=A0 =C2=A0 "logo_url": "https://loadsamoney/business/logo.png=
"
> =C2=A0 =C2=A0 },
> =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 "authorization_endpoint": "https://loadsamoney/con=
sumer/auth",
> =C2=A0 =C2=A0 =C2=A0 "description": "loadsmoney personal customers",
> =C2=A0 =C2=A0 =C2=A0 "logo_url": "https://loadsamoney/consumer/logo.png=
"
> =C2=A0 =C2=A0 }
> =C2=A0 ]
> }
>
> And as you say, the existing authorization_endpoint can be a fallback
> for clients that are unaware of the new spec or prefer the simpler
> option of just using a single authorization endpoint. Supporting the
> new spec would allow a better UX though so there=E2=80=99s advantages t=
o
> client to do so.
>>
>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be
>> sensibly combined with the proposed multi-brand spec.
>>
> I think that particular part is not really an issue as mtls isn=E2=80=99=
t used
> at the authorization endpoint.
>
> Thanks
>
> Joseph
>
>
>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov > > wrote:
>>
>> Hi Dave,
>>
>> In the absence of such a "multi-brand" spec we have tackled this
>> issue in the past by letting the "brand" be encoded in the client_id.
>> An alternative scenario is to do a "brand" lookup by client_id. Then
>> let the AS render the "branded" authZ endpoint.
>>
>> You're probably aware the mTLS spec is allowing for endpoint aliases,
>> so this is not the first time such as need has occurred:
>>
>> https://tools.ietf.org/html/rfc8705#section-5
>>
>> One could devise a similar JSON object with mappings "label" -
>> "authorization_endpoint".
>>
>> Clients that are aware of the new spec will look it up, those that
>> are not will fall back to the std "authorization_endpoint".
>>
>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be
>> sensibly combined with the proposed multi-brand spec.
>>
>>
>> Vladimir
>>
>>
>> On 20/05/2020 15:07, Dave Tonge wrote:
>>> Dear OAuth WG
>>>
>>> We have an issue
>>> 
>>> in the OpenID FAPI Working Group that we believe affects the wider
>>> OAuth community.
>>>
>>> In summary: *what is the recommended approach to discovery (RFC8414)
>>> for Authorization Servers=C2=A0who support multiple "brands" .*
>>>
>>> If brands are completely separate, then it seems sensible that each
>>> brand must have its own `issuer` and therefore its own discovery
>>> document at the correct location (i.e. brand 1 would have an issuer
>>> of "https://as/brand1" and a discovery document available at=C2=A0
>>> https://as/.well-known/oauth-authorization-server/brand1).
>>>
>>> However in the real world it is not always so simple. We have many
>>> existing implementations in UK open banking that support=C2=A0multipl=
e
>>> authorization endpoints. Here is an example (thanks to=C2=A0@Joseph
>>> Heenan =C2=A0)
>>>
>>> > Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet ba=
nking, one
>>> =E2=80=9Clogin page=E2=80=9D for both business and personal customers=
=2E
>>>
>>> > They have separate mobile apps for business/personal, and are
>>> required to support app2app. This means they will definitely be
>>> exposing multiple authorization endpoints (as there=E2=80=99s a 1:1 m=
apping
>>> of authorization endpoints to mobile apps) - the choice is how they
>>> do this.
>>>
>>> > Their choices are:
>>>
>>> > 1. Multiple discovery endpoints (one for business, one for
>>> personal), each with a different authorization endpoint, multiple
>>> issuers (if their vendor allows this)
>>> > 2. Single discovery endpoint, single issuer, multiple
>>> authorization endpoints listed in one discovery doc (one for
>>> business, one for personal) some of which are hardcoded by the 3rd pa=
rty
>>> > 3. Multiple discovery endpoints each with a different
>>> authorization endpoint, same issuer in all cases (breaks RFC8414 and
>>> OIDC Discovery)
>>>
>>> Option 3 is invalid and that leaves us with options 1 and 2.=C2=A0
>>> Option 1 can be problematic as often it is in reality the same
>>> `issuer` behind the scenes.
>>>
>>> We would like to get feedback on this issue and potentially an
>>> extension to RFC8414 to allow the definition of multiple
>>> authorization endpoints.
>>>
>>> Thanks in advance
>>>
>>> Dave Tonge
>>> Co-Chair FAPI WG
>>> Open ID Foundation
>>>
>>>
>>
>
--=20
Vladimir Dzhuvinov


--------------15EEEA6A56145CD278395228
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
A mapping like the one you propose can definitely work. Since the
      user will be making the choice which endpoint to take with the
      client app, having the logo_uri is a good idea. If the branded
      endpoints differ somehow in policy one could also allow inclusion
      of the op_policy_uri and op_tos_uri params from Discovery.

    
https://openid.net/s=
pecs/openid-connect-discovery-1_0.html#IssuerDiscovery

    
Vladimir

    

    
On 20/05/2020 19:16, Joseph Heenan
      wrote:

    

    

      
      Thanks for your thoughts Vladimir!
      


      

      
The client_id based solution I wasn=E2=80=99t previ=
ously
        aware of - unfortunately it doesn=E2=80=99t solve the problem for=

        app2app, as the mobile OS selects the app to use based purely on
        the URL (and in at least the iOS case will not offer the user a
        choice if multiple apps claim to handle the same url).

      


      

      
I think some kind of mapping like you suggest will
        work and fallback, I wonder about a structure in the
        authorization server metadata something like this:

      


      

      

        
{

        
=C2=A0 ...

        
=C2=A0 "alternative_authorization_endpoints": [
        
=C2=A0 =C2=A0 {

        
=C2=A0 =C2=A0 =C2=A0 "authorization_endpoint": "<=
a
            href=3D"https://loadsamoney/business/auth" class=3D""
            moz-do-not-send=3D"true">https://loadsamoney/business/auth",

        
=C2=A0 =C2=A0 =C2=A0 "description": "loadsmoney b=
usiness banking
          customers",

        
=C2=A0 =C2=A0 =C2=A0 "logo_url": "https://loadsamoney/business/logo.pn=
g"

        
=C2=A0 =C2=A0 },

        
=C2=A0 =C2=A0 {

        
=C2=A0 =C2=A0 =C2=A0 "authorization_endpoint": "<=
a
            href=3D"https://loadsamoney/consumer/auth" class=3D""
            moz-do-not-send=3D"true">https://loadsamoney/consumer/auth",

        
=C2=A0 =C2=A0 =C2=A0 "description": "loadsmoney p=
ersonal
          customers",

        
=C2=A0 =C2=A0 =C2=A0 "logo_url": "https://loadsamoney/consumer/logo.pn=
g"

        
=C2=A0 =C2=A0 }

        
=C2=A0 ]

        
}

      

      


      

      
And as you say, the existing authorization_endpoint=

        can be a fallback for clients that are unaware of the new spec
        or prefer the simpler option of just using a single
        authorization endpoint. Supporting the new spec would allow a
        better UX though so there=E2=80=99s advantages to client to do so=
=2E

      

        

          

            
Speaking of mTLS, I'm not sure how the
              "mtls_endpoint_aliases" can be sensibly combined with the
              proposed multi-brand spec.

          

        

      

      

        

          
I think that particular part is not really an
            issue as mtls isn=E2=80=99t used at the authorization endpoin=
t.

        

      

      
Thanks

      


      

      
Joseph

      


        


          

            
On 20 May 2020, at 16:07, Vladimir Dzhuvinov
              <vladimir@connect2id.com>
              wrote:

            

            

              
              

                
Hi Dave,

                
In the absence of such a "multi-brand" spec=

                  we have tackled this issue in the past by letting the
                  "brand" be encoded in the client_id. An alternative
                  scenario is to do a "brand" lookup by client_id. Then
                  let the AS render the "branded" authZ endpoint.

                
You're probably aware the mTLS spec is
                  allowing for endpoint aliases, so this is not the
                  first time such as need has occurred:

                
https://tools.ietf.org/html/=
rfc8705#section-5

                
One could devise a similar JSON object with=

                  mappings "label" - "authorization_endpoint".

                
Clients that are aware of the new spec will=

                  look it up, those that are not will fall back to the
                  std "authorization_endpoint".

                
Speaking of mTLS, I'm not sure how the
                  "mtls_endpoint_aliases" can be sensibly combined with
                  the proposed multi-brand spec.

                


                

                
Vladimir

                

                


                

                
On 20/05/2020 15:07, Dave
                  Tonge wrote:

                

                

                  
                  

                    
Dear
                      OAuth WG

                    


                    

                    
We
                      have an issue in =
the
                      OpenID FAPI Working Group that we believe affects
                      the wider OAuth community.

                    


                    

                    
In
                      summary: what is the recommended
                        approach to discovery (RFC8414) for
                        Authorization Servers=C2=A0who support multiple
                        "brands" .

                    


                    

                    
If
                      brands are completely separate, then it seems
                      sensible that each brand must have its own
                      `issuer` and therefore its own discovery document
                      at the correct location (i.e. brand 1 would have
                      an issuer of "https://as/br=
and1"
                      and a discovery document available at=C2=A0 https://as/.w=
ell-known/oauth-authoriz=
ation-server/brand1).

                    


                      

                    
However in the=

                        real world it is not always so simple. We have
                        many existing implementations in UK open banking
                        that support=C2=A0multiple authorization endpoint=
s.
                        Here is an example (thanks to=C2=A0@Josep=
h
                          Heenan=C2=A0)

                    


                      

                    
>
                      Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and,=
 for internet
                      banking, one =E2=80=9Clogin page=E2=80=9D for both =
business and
                      personal customers.

                      

                      > They have separate mobile apps for
                      business/personal, and are required to support
                      app2app. This means they will definitely be
                      exposing multiple authorization endpoints (as
                      there=E2=80=99s a 1:1 mapping of authorization endp=
oints
                      to mobile apps) - the choice is how they do this.
                      

                      > Their choices are:

                      

                      > 1. Multiple discovery endpoints (one for
                      business, one for personal), each with a different
                      authorization endpoint, multiple issuers (if their
                      vendor allows this)

                      > 2. Single discovery endpoint, single issuer,
                      multiple authorization endpoints listed in one
                      discovery doc (one for business, one for personal)
                      some of which are hardcoded by the 3rd party

                      > 3. Multiple discovery endpoints each with a
                      different authorization endpoint, same issuer in
                      all cases (breaks RFC8414 and OIDC Discovery)

                    

                    


                    

                    

                      
Option 3 is invalid and
                        that leaves us with options 1 and 2.=C2=A0

                      
Option 1 can be problematic
                        as often it is in reality the same `issuer`
                        behind the scenes.

                      


                      

                      
We would like to get
                        feedback on this issue and potentially an
                        extension to RFC8414 to allow the definition of
                        multiple authorization endpoints.

                      


                      

                      
Thanks in advance

                      


                      

                      
Dave Tonge

                      
Co-Chair FAPI WG

                      
Open ID Foundation

                      


                      

                    

                    


                    

                  

                

                

              

            

          

        

        

      

    

    
--=20
Vladimir Dzhuvinov

  


--------------15EEEA6A56145CD278395228--

--------------ms070006080209000105010900
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
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjIwNjEwMTZaMC8G
CSqGSIb3DQEJBDEiBCAnPv2a54SfFwm8b5d05RVFgoWze8zXPEyx+6YDOFwRITBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBABeF5hh/d6YAjjEfU3plQbdrjPmc5Alz3Q8fbATo98GoMPPQ
i4FSqH5S5mPAD4D11Av+vvxZO/i5IiA32GCQQFjg92mjk+Lf6TWdmlQij+ByfQt31VPyyXce
Y+mdZ0x2TEI9CloDJNJqtWm4DtiUynGM3H1lhlUxLUaAQTybLA6tC/e/Tq8iX37VHhsW04+8
v0bpljwupN7X/z3pnmMXgbm346L3hs17TgbykxLEJI6q/abVNKZRMvXRF3aai7ShYKb5ondJ
2orwYOGLxsKFMotrUewvHBrFAyZrqlZHB3BsQLPeXF2SH6MPBRPWqZbqMredbbhlcc65Sfg4
usjOaLcAAAAAAAA=
--------------ms070006080209000105010900--


From nobody Thu May 21 23:59:13 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAFE3A0F05 for ; Thu, 21 May 2020 23:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqNVqL6Z8DcF for ; Thu, 21 May 2020 23:59:09 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABD03A0F01 for ; Thu, 21 May 2020 23:59:09 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id x1so11745126ejd.8 for ; Thu, 21 May 2020 23:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HnpmgqJFoq3NejT2rePXsrbISM76Ue/rtXXEFuCjK8c=; b=DEfPBGWKPZOJG37q9xMALsM5nBl0zxvYRxEGbVoO1ksO9jjTm1kly+bkeMz49smy5G tJVcg/bf+ZjzHDbAelmyRHOFyxt9wbxOp1K4V6loBID1TauK62fqHppZV9xDJsW/a0lU 3NSkWGlfEs3hrkQt05xZcE7rRRifPLcC6iIZTdUgF0+WcuSjZS6x3YPmMUu1zoKOrru4 u0jne1OgFZlVXJljOOqYV1WDaCfUjdRjhtx3Kq1eioUmBVus80yyFzLAD0l6E9Lngtse +0oww29U3pPmgG5APFKLYzhgv+/HhRfe5TYkuQCmf8pYss+zHW7NEtrXsVeXMRMHWeeH 1AMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HnpmgqJFoq3NejT2rePXsrbISM76Ue/rtXXEFuCjK8c=; b=WJjckkTbbkZ28h2gNVSeFe5CqJeRM0EeI5dJZAmlfOu5lW/8uzP9/8+03epzbh4TuL TADk3BxJEI59+dg6xBreRjhaJsM8vwg3fhAOrbVDIHQwwJHR6QcZlIpqmULlME9YS2yq dUn0byng98Bmf3t5i39RmecwHb52LKj+isOs9Que6W7Cfi9TU4SFUxh40yCEHMkRBifj 6nxD3trWPDmXKzlb9LU+P+SH5sifAXfMErNvVuaIHoztEdC25zgGgAZRIQDfNBM2cqxv ctvgTmvJipNWE/H0JvxpBAfzOE2oV4YuohPK/OTV6tOwCZ3u6MhtYCZyN8eigmL9XgmK ALhw==
X-Gm-Message-State: AOAM532zYn6QVJzrTcpgcWY5K7rnIi93lxdB7taQWhnbgvl7V1UwaHNd WRfubg+mRTFLGVXn1TtS5/MbDsz+xY0=
X-Google-Smtp-Source: ABdhPJyjBbKWrxpYQGyZ+GFUmNLe1ftrLuxxWNM2EyOncfDMVEkIqpPxxRA4WZWLpj9rP4IGcPbWIw==
X-Received: by 2002:a17:906:160a:: with SMTP id m10mr7221680ejd.170.1590130745942;  Thu, 21 May 2020 23:59:05 -0700 (PDT)
Received: from p200300eb8f3b3fc8904241d200c1eeb6.dip0.t-ipconnect.de (p200300eb8f3b3fc8904241d200c1eeb6.dip0.t-ipconnect.de. [2003:eb:8f3b:3fc8:9042:41d2:c1:eeb6]) by smtp.gmail.com with ESMTPSA id cm26sm6268958edb.87.2020.05.21.23.59.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2020 23:59:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com>
Date: Fri, 22 May 2020 08:59:03 +0200
Cc: Joseph Heenan , Openid-specs-fapi , oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net>
References:  <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com>
To: Vladimir Dzhuvinov 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 May 2020 06:59:12 -0000

I think an id or label per endpoint set would be needed to determine the =
set of endpoints to be used by a certain client.

On the conceptual side, I=E2=80=99m asking myself how the complete =
process is supposed to work. Who is deciding what issuer/endpoint set =
combination to use. I assume in an open banking scenario, there will =
always be some kind of bank chooser. Will this chooser provide the =
client with issuer and brand id?=20

> On 22. May 2020, at 08:10, Vladimir Dzhuvinov =
 wrote:
>=20
> A mapping like the one you propose can definitely work. Since the user =
will be making the choice which endpoint to take with the client app, =
having the logo_uri is a good idea. If the branded endpoints differ =
somehow in policy one could also allow inclusion of the op_policy_uri =
and op_tos_uri params from Discovery.
>=20
> =
https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery=

>=20
> Vladimir
>=20
> On 20/05/2020 19:16, Joseph Heenan wrote:
>> Thanks for your thoughts Vladimir!
>>=20
>> The client_id based solution I wasn=E2=80=99t previously aware of - =
unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile OS selects the app to use based purely on the URL (and in at =
least the iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).
>>=20
>> I think some kind of mapping like you suggest will work and fallback, =
I wonder about a structure in the authorization server metadata =
something like this:
>>=20
>> {
>>   ...
>>   "alternative_authorization_endpoints": [
>>     {
>>       "authorization_endpoint": "https://loadsamoney/business/auth",
>>       "description": "loadsmoney business banking customers",
>>       "logo_url": "https://loadsamoney/business/logo.png"
>>     },
>>     {
>>       "authorization_endpoint": "https://loadsamoney/consumer/auth",
>>       "description": "loadsmoney personal customers",
>>       "logo_url": "https://loadsamoney/consumer/logo.png"
>>     }
>>   ]
>> }
>>=20
>> And as you say, the existing authorization_endpoint can be a fallback =
for clients that are unaware of the new spec or prefer the simpler =
option of just using a single authorization endpoint. Supporting the new =
spec would allow a better UX though so there=E2=80=99s advantages to =
client to do so.
>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can =
be sensibly combined with the proposed multi-brand spec.
>>>=20
>> I think that particular part is not really an issue as mtls isn=E2=80=99=
t used at the authorization endpoint.
>>=20
>> Thanks
>>=20
>> Joseph
>>=20
>>=20
>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov =
 wrote:
>>>=20
>>> Hi Dave,
>>>=20
>>> In the absence of such a "multi-brand" spec we have tackled this =
issue in the past by letting the "brand" be encoded in the client_id. An =
alternative scenario is to do a "brand" lookup by client_id. Then let =
the AS render the "branded" authZ endpoint.
>>>=20
>>> You're probably aware the mTLS spec is allowing for endpoint =
aliases, so this is not the first time such as need has occurred:
>>>=20
>>> https://tools.ietf.org/html/rfc8705#section-5
>>>=20
>>> One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".
>>>=20
>>> Clients that are aware of the new spec will look it up, those that =
are not will fall back to the std "authorization_endpoint".
>>>=20
>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can =
be sensibly combined with the proposed multi-brand spec.
>>>=20
>>>=20
>>>=20
>>> Vladimir
>>>=20
>>>=20
>>>=20
>>> On 20/05/2020 15:07, Dave Tonge wrote:
>>>> Dear OAuth WG
>>>>=20
>>>> We have an issue in the OpenID FAPI Working Group that we believe =
affects the wider OAuth community.
>>>>=20
>>>> In summary: what is the recommended approach to discovery (RFC8414) =
for Authorization Servers who support multiple "brands" .
>>>>=20
>>>> If brands are completely separate, then it seems sensible that each =
brand must have its own `issuer` and therefore its own discovery =
document at the correct location (i.e. brand 1 would have an issuer of =
"https://as/brand1" and a discovery document available at  =
https://as/.well-known/oauth-authorization-server/brand1).
>>>>=20
>>>> However in the real world it is not always so simple. We have many =
existing implementations in UK open banking that support multiple =
authorization endpoints. Here is an example (thanks to @Joseph Heenan )
>>>>=20
>>>> > Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet =
banking, one =E2=80=9Clogin page=E2=80=9D for both business and personal =
customers.
>>>>=20
>>>> > They have separate mobile apps for business/personal, and are =
required to support app2app. This means they will definitely be exposing =
multiple authorization endpoints (as there=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.
>>>>=20
>>>> > Their choices are:
>>>>=20
>>>> > 1. Multiple discovery endpoints (one for business, one for =
personal), each with a different authorization endpoint, multiple =
issuers (if their vendor allows this)
>>>> > 2. Single discovery endpoint, single issuer, multiple =
authorization endpoints listed in one discovery doc (one for business, =
one for personal) some of which are hardcoded by the 3rd party
>>>> > 3. Multiple discovery endpoints each with a different =
authorization endpoint, same issuer in all cases (breaks RFC8414 and =
OIDC Discovery)
>>>>=20
>>>> Option 3 is invalid and that leaves us with options 1 and 2.=20
>>>> Option 1 can be problematic as often it is in reality the same =
`issuer` behind the scenes.
>>>>=20
>>>> We would like to get feedback on this issue and potentially an =
extension to RFC8414 to allow the definition of multiple authorization =
endpoints.
>>>>=20
>>>> Thanks in advance
>>>>=20
>>>> Dave Tonge
>>>> Co-Chair FAPI WG
>>>> Open ID Foundation
>>>>=20
>>>>=20
>>>=20
>>=20
> --=20
> Vladimir Dzhuvinov
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri May 22 00:52:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE953A0A0B for ; Fri, 22 May 2020 00:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtQIlzoVkTwH for ; Fri, 22 May 2020 00:52:12 -0700 (PDT)
Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (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 593BF3A07CE for ; Fri, 22 May 2020 00:52:12 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id c2TQj99H0UpoQc2TRj0gmn; Fri, 22 May 2020 00:52:11 -0700
x-spam-cmae: v=2.3 cv=C9SXNjH+ c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=48vgC7mUAAAA:8 a=d3zCVR3oQ2Bl2PlXulcA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=cS2Fm5A1SFEntd8t:21 a=XxFVu_QeCrdj8Z_A:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=058By5spHmhxsZOHdMEA:9 a=3RP4rZn5U4b9dSmJ:21 a=vPJilCChBJUvBDqY:21 a=MWNR8Cv-JauBcsp_:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
X-CMAE-Analysis: v=2.3 cv=C9SXNjH+ c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=48vgC7mUAAAA:8 a=d3zCVR3oQ2Bl2PlXulcA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=cS2Fm5A1SFEntd8t:21 a=XxFVu_QeCrdj8Z_A:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=058By5spHmhxsZOHdMEA:9 a=3RP4rZn5U4b9dSmJ:21 a=vPJilCChBJUvBDqY:21 a=MWNR8Cv-JauBcsp_:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Torsten Lodderstedt 
Cc: Joseph Heenan , Openid-specs-fapi , oauth 
References:  <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com> <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net>
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <99394ea7-4588-5a5e-6997-bb96a19a1196@connect2id.com>
Date: Fri, 22 May 2020 10:52:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040607050104010804090001"
X-CMAE-Envelope: MS4wfCTCCIvkpcSkg7GaCiRuGKnrJSqGRXlm7p3s3iyuZOPG5Lsx+mXKDEz3+oskWICHOrDvyrNN39GG1m7BK/ZX91f9JqgmyTcXgtU7v0qQyxzR0ThXCGZb ckXaEEHGUnC7QlUxqE0SCneZADVASauOHD+Xg7cNZpFKFqccj0QRRH5IaKeBp7JA7ZmAfMrB8MIAETXGWWoR3amXpnOMxn7EC91Uuds8wzGqP8BxANhUXQ0f 1pFp+MzfRxgQPM5G2dfhBgi3OwJ1/SOujyDzsjUBz7xhxDD8XircPogPrh124eWg
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 May 2020 07:52:17 -0000

This is a cryptographically signed message in MIME format.

--------------ms040607050104010804090001
Content-Type: multipart/alternative;
 boundary="------------7BEAFDC57463DC52A84464EB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------7BEAFDC57463DC52A84464EB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

With that said it makes sense to devise a structure which can
accommodate UI driven as well as automatic choice.

  * The UI driven chooser will need a human readable description and
    other UI hints. This can work for instance with "classic" OIDC
    Discovery.

  * The "auto" chooser will need some sort of an ID. For a bank chooser
    this means providing the issuer URI and an optional brand ID and
    both must get registered together. Or, one could define a standard
    brand ID (label) for banking operations and if the
    "alternative_authorization_endpoints" is present look for it in the
    structure, else fall back to the default "authorization_endpoint".

Here is one possible layout which has IDs and UI hints:

{
  ...
  "alternative_authorization_endpoints": {
    "banking": {
      "authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
    },
    "personal": {
      "authorization_endpoint": "https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
    }
  }
}


On 22/05/2020 09:59, Torsten Lodderstedt wrote:
> I think an id or label per endpoint set would be needed to determine th=
e set of endpoints to be used by a certain client.
>
> On the conceptual side, I=E2=80=99m asking myself how the complete proc=
ess is supposed to work. Who is deciding what issuer/endpoint set combina=
tion to use. I assume in an open banking scenario, there will always be s=
ome kind of bank chooser. Will this chooser provide the client with issue=
r and brand id?=20
>
>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov  wrote:
>>
>> A mapping like the one you propose can definitely work. Since the user=
 will be making the choice which endpoint to take with the client app, ha=
ving the logo_uri is a good idea. If the branded endpoints differ somehow=
 in policy one could also allow inclusion of the op_policy_uri and op_tos=
_uri params from Discovery.
>>
>> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDisco=
very
>>
>> Vladimir
>>
>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>> Thanks for your thoughts Vladimir!
>>>
>>> The client_id based solution I wasn=E2=80=99t previously aware of - u=
nfortunately it doesn=E2=80=99t solve the problem for app2app, as the mob=
ile OS selects the app to use based purely on the URL (and in at least th=
e iOS case will not offer the user a choice if multiple apps claim to han=
dle the same url).
>>>
>>> I think some kind of mapping like you suggest will work and fallback,=
 I wonder about a structure in the authorization server metadata somethin=
g like this:
>>>
>>> {
>>>   ...
>>>   "alternative_authorization_endpoints": [
>>>     {
>>>       "authorization_endpoint": "https://loadsamoney/business/auth",
>>>       "description": "loadsmoney business banking customers",
>>>       "logo_url": "https://loadsamoney/business/logo.png"
>>>     },
>>>     {
>>>       "authorization_endpoint": "https://loadsamoney/consumer/auth",
>>>       "description": "loadsmoney personal customers",
>>>       "logo_url": "https://loadsamoney/consumer/logo.png"
>>>     }
>>>   ]
>>> }
>>>
>>> And as you say, the existing authorization_endpoint can be a fallback=
 for clients that are unaware of the new spec or prefer the simpler optio=
n of just using a single authorization endpoint. Supporting the new spec =
would allow a better UX though so there=E2=80=99s advantages to client to=
 do so.
>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can b=
e sensibly combined with the proposed multi-brand spec.
>>>>
>>> I think that particular part is not really an issue as mtls isn=E2=80=
=99t used at the authorization endpoint.
>>>
>>> Thanks
>>>
>>> Joseph
>>>
>>>
>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov  wrote:
>>>>
>>>> Hi Dave,
>>>>
>>>> In the absence of such a "multi-brand" spec we have tackled this iss=
ue in the past by letting the "brand" be encoded in the client_id. An alt=
ernative scenario is to do a "brand" lookup by client_id. Then let the AS=
 render the "branded" authZ endpoint.
>>>>
>>>> You're probably aware the mTLS spec is allowing for endpoint aliases=
, so this is not the first time such as need has occurred:
>>>>
>>>> https://tools.ietf.org/html/rfc8705#section-5
>>>>
>>>> One could devise a similar JSON object with mappings "label" - "auth=
orization_endpoint".
>>>>
>>>> Clients that are aware of the new spec will look it up, those that a=
re not will fall back to the std "authorization_endpoint".
>>>>
>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can b=
e sensibly combined with the proposed multi-brand spec.
>>>>
>>>>
>>>>
>>>> Vladimir
>>>>
>>>>
>>>>
>>>> On 20/05/2020 15:07, Dave Tonge wrote:
>>>>> Dear OAuth WG
>>>>>
>>>>> We have an issue in the OpenID FAPI Working Group that we believe a=
ffects the wider OAuth community.
>>>>>
>>>>> In summary: what is the recommended approach to discovery (RFC8414)=
 for Authorization Servers who support multiple "brands" .
>>>>>
>>>>> If brands are completely separate, then it seems sensible that each=
 brand must have its own `issuer` and therefore its own discovery documen=
t at the correct location (i.e. brand 1 would have an issuer of "https://=
as/brand1" and a discovery document available at  https://as/.well-known/=
oauth-authorization-server/brand1).
>>>>>
>>>>> However in the real world it is not always so simple. We have many =
existing implementations in UK open banking that support multiple authori=
zation endpoints. Here is an example (thanks to @Joseph Heenan )
>>>>>
>>>>>> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet b=
anking, one =E2=80=9Clogin page=E2=80=9D for both business and personal c=
ustomers.
>>>>>> They have separate mobile apps for business/personal, and are requ=
ired to support app2app. This means they will definitely be exposing mult=
iple authorization endpoints (as there=E2=80=99s a 1:1 mapping of authori=
zation endpoints to mobile apps) - the choice is how they do this.
>>>>>> Their choices are:
>>>>>> 1. Multiple discovery endpoints (one for business, one for persona=
l), each with a different authorization endpoint, multiple issuers (if th=
eir vendor allows this)
>>>>>> 2. Single discovery endpoint, single issuer, multiple authorizatio=
n endpoints listed in one discovery doc (one for business, one for person=
al) some of which are hardcoded by the 3rd party
>>>>>> 3. Multiple discovery endpoints each with a different authorizatio=
n endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)
>>>>> Option 3 is invalid and that leaves us with options 1 and 2.=20
>>>>> Option 1 can be problematic as often it is in reality the same `iss=
uer` behind the scenes.
>>>>>
>>>>> We would like to get feedback on this issue and potentially an exte=
nsion to RFC8414 to allow the definition of multiple authorization endpoi=
nts.
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>> Dave Tonge
>>>>> Co-Chair FAPI WG
>>>>> Open ID Foundation
>>>>>
>>>>>
>> --=20
>> Vladimir Dzhuvinov
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov


--------------7BEAFDC57463DC52A84464EB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
With that said it makes sense to devise a structure which can
      accommodate UI driven as well as automatic choice.

    
    
      
  • The UI driven chooser will need a human readable description
        and other UI hints. This can work for instance with "classic"
        OIDC Discovery.
    
        
    
      
    • 
      
  • The "auto" chooser will need some sort of an ID. For a bank
        chooser this means providing the issuer URI and an optional
        brand ID and both must get registered together. Or, one could
        define a standard brand ID (label) for banking operations and if
        the "alternative_authorization_endpoints" is present look for it
        in the structure, else fall back to the default
        "authorization_endpoint".
      
    • 
    

    
Here is one possible layout which has IDs and UI hints:

    

    
{
  ...
  "alternative_authorization_endpoints": {
    "banking": {
      "authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
    },
    "personal": {
      "authorization_endpoint": "https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
    }
  }
}

    


    

    
On 22/05/2020 09:59, Torsten
      Lodderstedt wrote:

    

    

      
I think an id or label per e=
ndpoint set would be needed to determine the set of endpoints to be used =
by a certain client.

On the conceptual side, I=E2=80=99m asking myself how the complete proces=
s is supposed to work. Who is deciding what issuer/endpoint set combinati=
on to use. I assume in an open banking scenario, there will always be som=
e kind of bank chooser. Will this chooser provide the client with issuer =
and brand id?=20



      

        
On 22. May 2020, at 08:10,=
 Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

A mapping like the one you propose can definitely work. Since the user wi=
ll be making the choice which endpoint to take with the client app, havin=
g the logo_uri is a good idea. If the branded endpoints differ somehow in=
 policy one could also allow inclusion of the op_policy_uri and op_tos_ur=
i params from Discovery.

https://openid.net/specs/op=
enid-connect-discovery-1_0.html#IssuerDiscovery

Vladimir

On 20/05/2020 19:16, Joseph Heenan wrote:


        

          
Thanks for your thoughts=
 Vladimir!

The client_id based solution I wasn=E2=80=99t previously aware of - unfor=
tunately it doesn=E2=80=99t solve the problem for app2app, as the mobile =
OS selects the app to use based purely on the URL (and in at least the iO=
S case will not offer the user a choice if multiple apps claim to handle =
the same url).

I think some kind of mapping like you suggest will work and fallback, I w=
onder about a structure in the authorization server metadata something li=
ke this:

{
  ...
  "alternative_authorization_endpoints": [
    {
      "authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
    },
    {
      "authorization_endpoint": "https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
    }
  ]
}

And as you say, the existing authorization_endpoint can be a fallback for=
 clients that are unaware of the new spec or prefer the simpler option of=
 just using a single authorization endpoint. Supporting the new spec woul=
d allow a better UX though so there=E2=80=99s advantages to client to do =
so.


          

            
Speaking of mTLS, I'm =
not sure how the "mtls_endpoint_aliases" can be sensibly combined with th=
e proposed multi-brand spec.



          

          
I think that particular =
part is not really an issue as mtls isn=E2=80=99t used at the authorizati=
on endpoint.

Thanks

Joseph




          

            
On 20 May 2020, at 16:=
07, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

Hi Dave,

In the absence of such a "multi-brand" spec we have tackled this issue in=
 the past by letting the "brand" be encoded in the client_id. An alternat=
ive scenario is to do a "brand" lookup by client_id. Then let the AS rend=
er the "branded" authZ endpoint.

You're probably aware the mTLS spec is allowing for endpoint aliases, so =
this is not the first time such as need has occurred:

https://tools.ietf.org/html/rfc8705#section-5

One could devise a similar JSON object with mappings "label" - "authoriza=
tion_endpoint".

Clients that are aware of the new spec will look it up, those that are no=
t will fall back to the std "authorization_endpoint".

Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be sen=
sibly combined with the proposed multi-brand spec.



Vladimir



On 20/05/2020 15:07, Dave Tonge wrote:


            

              
Dear OAuth WG

We have an issue in the OpenID FAPI Working Group that we believe affects=
 the wider OAuth community.

In summary: what is the recommended approach to discovery (RFC8414) for A=
uthorization Servers who support multiple "brands" .

If brands are completely separate, then it seems sensible that each brand=
 must have its own `issuer` and therefore its own discovery document at t=
he correct location (i.e. brand 1 would have an issuer of "https://as/brand1" an=
d a discovery document available at  https://=
as/.well-known/oauth-authorization-server/brand1).

However in the real world it is not always so simple. We have many existi=
ng implementations in UK open banking that support multiple authorization=
 endpoints. Here is an example (thanks to @Joseph Heenan )



              

                
Bank =E2=80=9Cload=
samoney=E2=80=9D has one idp and, for internet banking, one =E2=80=9Clogi=
n page=E2=80=9D for both business and personal customers.


              

              

              

                
They have separate=
 mobile apps for business/personal, and are required to support app2app. =
This means they will definitely be exposing multiple authorization endpoi=
nts (as there=E2=80=99s a 1:1 mapping of authorization endpoints to mobil=
e apps) - the choice is how they do this.


              

              

              

                
Their choices are:=



              

              

              

                
1. Multiple discov=
ery endpoints (one for business, one for personal), each with a different=
 authorization endpoint, multiple issuers (if their vendor allows this)
2. Single discovery endpoint, single issuer, multiple authorization endpo=
ints listed in one discovery doc (one for business, one for personal) som=
e of which are hardcoded by the 3rd party
3. Multiple discovery endpoints each with a different authorization endpo=
int, same issuer in all cases (breaks RFC8414 and OIDC Discovery)


              

              
Option 3 is invalid and that leaves us with options 1 and 2.=20
Option 1 can be problematic as often it is in reality the same `issuer` b=
ehind the scenes.

We would like to get feedback on this issue and potentially an extension =
to RFC8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG
Open ID Foundation




            

            

          

          

        

        
--=20
Vladimir Dzhuvinov

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


      

      

    

    
--=20
Vladimir Dzhuvinov

  


--------------7BEAFDC57463DC52A84464EB--

--------------ms040607050104010804090001
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
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjIwNzUyMDhaMC8G
CSqGSIb3DQEJBDEiBCBoNFGJErhDNxurUEgS3onarv1ikbFe7uVaLCtppCzRcDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAAZk0CZtOyeKZcgYtWU7UvrW0O37oDnkolyxAGhPvFo6O78O
Z+diNYdUiDupmjEl15o+7OPOFv2bV6YFDEw9pm3PhP0d2kOD8n8GJVu3MvnTk51oKyByLm+b
TqHVsSXhOTy+zbVXlxrA6qsIX5Z0bXFNbwuJwZvmivD0KW3eEXZhWt1vGin0Vx3WAx4Sl+Px
I8Ez3FeBdvIE2lMThWvXme3iEzRxMfskE0N1FBHiof2MI9G8e9Iv2p3XWegDAl1RTDSweTFX
kFKeFB6PkCCvOVi3AN4gOV9mYMk7NyWmcRp+oVgyOR5k86bgz0el2sawZwU1VQlQJG4Jb+cr
QMn94esAAAAAAAA=
--------------ms040607050104010804090001--


From nobody Fri May 22 01:32:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC473A0743 for ; Fri, 22 May 2020 01:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPylhAQ6eVex for ; Fri, 22 May 2020 01:32:07 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED1D3A0659 for ; Fri, 22 May 2020 01:32:06 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id z4so7887170wmi.2 for ; Fri, 22 May 2020 01:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XEQmKtFfPiuvWsca+mXdPHSZ2OHCeVs4IEO8GZSytig=; b=apze71QNyHoQBL3w1o6sIwutnNFYWUGmfEjiytcLudI/iqM/JIX+H6Ha5tlFfU0DmZ os5lYprzMKnro2wv+Ep2SbSDcsCAYGjHnTmbuNw2C6IMKu8rMPeqddRKreWqntZXEwce O9nUQmas4rvbwKpAsCIcwur3lSAio2OymQRz7gplRlur8SLRgHRL3d0XxxDPee3GAMid FGVzZ655zacJVMdYNj/lf1EWDk1G0AgccvuQQnXOyH8Gq9d+ylCcPL8r5u53OE37554O Hf+NKGleNQSBqFmdWowXgpXQKfAj46IIG9kAA71ZwxlH7we/gM9fIzx6RknbuMBfpfov Ummw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XEQmKtFfPiuvWsca+mXdPHSZ2OHCeVs4IEO8GZSytig=; b=aiCKp4YgEvjl+JoDuUQLxExzXTY9rVDhYOlFvDOYACuOEPW9XT42T/Pt50uYKWetsK CHjArMegLe0ChyriaLmuOAnY/oj9479E5sGDM1IN0DqWEv9yYf/zNARcHlNgnZ7KGGgq cMyq03zykW5od61ExDHumLGpo7tbe3aidAkHT+4En+hlYuXPygpTZHSHOTM2QsWH5k+G olaV26/l1np26mEqfu8TolZ8x6ETuLBvUZ6K3u+LMWQpMtgAA4PWiT4ha76AGqgccLFX hONhM4jsiiosDq/GoTpJ9br9hSTVHpmzihbtCWJKqL5XEJ+O7YzsRFzbC9nJqdp9Cw48 MJ7Q==
X-Gm-Message-State: AOAM533w6SCOb7d/KJCGI/GCrGOw7u0EzmstglY0zF+kqzk7sBPC0zTw LB7IVPJdbauTCTIwLKkveeHA0w==
X-Google-Smtp-Source: ABdhPJwB77sD/nmv0HFihglA5uOpCUksk2rM1oBICmnc4DH3JkACI7z+zLlxdl7qkjx/qctDfze/ug==
X-Received: by 2002:a05:600c:228f:: with SMTP id 15mr12062377wmf.26.1590136323741;  Fri, 22 May 2020 01:32:03 -0700 (PDT)
Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id y204sm812198wmg.36.2020.05.22.01.32.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 01:32:03 -0700 (PDT)
From: Joseph Heenan 
Message-Id: <66FD701A-6036-4D6E-A2AB-E206A0043BBF@authlete.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6C5A7A34-4C3C-4CD5-BE03-C994FB9778F3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 22 May 2020 09:32:02 +0100
In-Reply-To: <99394ea7-4588-5a5e-6997-bb96a19a1196@connect2id.com>
Cc: Torsten Lodderstedt , Openid-specs-fapi , oauth 
To: Vladimir Dzhuvinov 
References:  <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com> <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net> <99394ea7-4588-5a5e-6997-bb96a19a1196@connect2id.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 May 2020 08:32:11 -0000

--Apple-Mail=_6C5A7A34-4C3C-4CD5-BE03-C994FB9778F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks Vladimir/Torsten.

I agree, it would make sense to have some form of static id for each =
entry. My first attempt started out similar but for some reason I =
decided to simplify=E2=80=A6

On the conceptual side for choosers (and biased towards how the UK =
openbanking ecosystem works as that=E2=80=99s what I know best), what =
this allows for is:

client chooser -> authorisation endpoint

Where the list is:

=E2=80=9CBank a=E2=80=9D
=E2=80=9CLoadsamoney personal=E2=80=9D
=E2=80=9CLoadsamoney business=E2=80=9D
=E2=80=9CBank c"


Instead of the only =E2=80=99standards compliant=E2=80=99 way to do =
app2app in this case today of:

client chooser -> AS interstitial chooser on authorization endpoint -> =
real authorization endpoint

Where the first chooser is:

=E2=80=9CBank a=E2=80=9D
=E2=80=9CLoadsamoney=E2=80=9D
=E2=80=9CBank c=E2=80=9D

And the second:

=E2=80=9CPersonal"
=E2=80=9CBusiness"

The first case is much better, particularly for the real multi-brand =
case where the end user might not even associate the two bank brandnames =
with each other.

What actually happens today is the first case (single RP chooser), but =
based on banks emailing around lists of alternative authorization =
endpoints to the RP, or publishing the details on obscure developer =
portals - which destroys much of the convenience / agility / security =
the server metadata RFC was trying achieve.

The issue of how the RP finds the server metadata document is unchanged =
from today. (In the UK, we have a centralised directory that lists =
them.)

Joseph



> On 22 May 2020, at 08:52, Vladimir Dzhuvinov  =
wrote:
>=20
> With that said it makes sense to devise a structure which can =
accommodate UI driven as well as automatic choice.
>=20
> The UI driven chooser will need a human readable description and other =
UI hints. This can work for instance with "classic" OIDC Discovery.
>=20
> The "auto" chooser will need some sort of an ID. For a bank chooser =
this means providing the issuer URI and an optional brand ID and both =
must get registered together. Or, one could define a standard brand ID =
(label) for banking operations and if the =
"alternative_authorization_endpoints" is present look for it in the =
structure, else fall back to the default "authorization_endpoint".
> Here is one possible layout which has IDs and UI hints:
>=20
> {
>   ...
>   "alternative_authorization_endpoints": {
>     "banking": {
>       "authorization_endpoint": "https://loadsamoney/business/auth" =
,
>       "description": "loadsmoney business banking customers",
>       "logo_url": "https://loadsamoney/business/logo.png" =

>     },
>     "personal": {
>       "authorization_endpoint": "https://loadsamoney/consumer/auth" =
,
>       "description": "loadsmoney personal customers",
>       "logo_url": "https://loadsamoney/consumer/logo.png" =

>     }
>   }
> }
>=20
>=20
> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>> I think an id or label per endpoint set would be needed to determine =
the set of endpoints to be used by a certain client.
>>=20
>> On the conceptual side, I=E2=80=99m asking myself how the complete =
process is supposed to work. Who is deciding what issuer/endpoint set =
combination to use. I assume in an open banking scenario, there will =
always be some kind of bank chooser. Will this chooser provide the =
client with issuer and brand id?=20
>>=20
>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov =
  wrote:
>>>=20
>>> A mapping like the one you propose can definitely work. Since the =
user will be making the choice which endpoint to take with the client =
app, having the logo_uri is a good idea. If the branded endpoints differ =
somehow in policy one could also allow inclusion of the op_policy_uri =
and op_tos_uri params from Discovery.
>>>=20
>>> =
https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery=
 =

>>>=20
>>> Vladimir
>>>=20
>>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>>> Thanks for your thoughts Vladimir!
>>>>=20
>>>> The client_id based solution I wasn=E2=80=99t previously aware of - =
unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile OS selects the app to use based purely on the URL (and in at =
least the iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).
>>>>=20
>>>> I think some kind of mapping like you suggest will work and =
fallback, I wonder about a structure in the authorization server =
metadata something like this:
>>>>=20
>>>> {
>>>>   ...
>>>>   "alternative_authorization_endpoints": [
>>>>     {
>>>>       "authorization_endpoint": "https://loadsamoney/business/auth" =
,
>>>>       "description": "loadsmoney business banking customers",
>>>>       "logo_url": "https://loadsamoney/business/logo.png" =

>>>>     },
>>>>     {
>>>>       "authorization_endpoint": "https://loadsamoney/consumer/auth" =
,
>>>>       "description": "loadsmoney personal customers",
>>>>       "logo_url": "https://loadsamoney/consumer/logo.png" =

>>>>     }
>>>>   ]
>>>> }
>>>>=20
>>>> And as you say, the existing authorization_endpoint can be a =
fallback for clients that are unaware of the new spec or prefer the =
simpler option of just using a single authorization endpoint. Supporting =
the new spec would allow a better UX though so there=E2=80=99s =
advantages to client to do so.
>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can =
be sensibly combined with the proposed multi-brand spec.
>>>>>=20
>>>> I think that particular part is not really an issue as mtls isn=E2=80=
=99t used at the authorization endpoint.
>>>>=20
>>>> Thanks
>>>>=20
>>>> Joseph
>>>>=20
>>>>=20
>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov =
  wrote:
>>>>>=20
>>>>> Hi Dave,
>>>>>=20
>>>>> In the absence of such a "multi-brand" spec we have tackled this =
issue in the past by letting the "brand" be encoded in the client_id. An =
alternative scenario is to do a "brand" lookup by client_id. Then let =
the AS render the "branded" authZ endpoint.
>>>>>=20
>>>>> You're probably aware the mTLS spec is allowing for endpoint =
aliases, so this is not the first time such as need has occurred:
>>>>>=20
>>>>> https://tools.ietf.org/html/rfc8705#section-5 =

>>>>>=20
>>>>> One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".
>>>>>=20
>>>>> Clients that are aware of the new spec will look it up, those that =
are not will fall back to the std "authorization_endpoint".
>>>>>=20
>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can =
be sensibly combined with the proposed multi-brand spec.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Vladimir
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
>>>>>> Dear OAuth WG
>>>>>>=20
>>>>>> We have an issue in the OpenID FAPI Working Group that we believe =
affects the wider OAuth community.
>>>>>>=20
>>>>>> In summary: what is the recommended approach to discovery =
(RFC8414) for Authorization Servers who support multiple "brands" .
>>>>>>=20
>>>>>> If brands are completely separate, then it seems sensible that =
each brand must have its own `issuer` and therefore its own discovery =
document at the correct location (i.e. brand 1 would have an issuer of =
"https://as/brand1"  and a discovery document =
available at  https://as/.well-known/oauth-authorization-server/brand1 =
).
>>>>>>=20
>>>>>> However in the real world it is not always so simple. We have =
many existing implementations in UK open banking that support multiple =
authorization endpoints. Here is an example (thanks to @Joseph Heenan )
>>>>>>=20
>>>>>>> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet =
banking, one =E2=80=9Clogin page=E2=80=9D for both business and personal =
customers.
>>>>>>> They have separate mobile apps for business/personal, and are =
required to support app2app. This means they will definitely be exposing =
multiple authorization endpoints (as there=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.
>>>>>>> Their choices are:
>>>>>>> 1. Multiple discovery endpoints (one for business, one for =
personal), each with a different authorization endpoint, multiple =
issuers (if their vendor allows this)
>>>>>>> 2. Single discovery endpoint, single issuer, multiple =
authorization endpoints listed in one discovery doc (one for business, =
one for personal) some of which are hardcoded by the 3rd party
>>>>>>> 3. Multiple discovery endpoints each with a different =
authorization endpoint, same issuer in all cases (breaks RFC8414 and =
OIDC Discovery)
>>>>>> Option 3 is invalid and that leaves us with options 1 and 2.=20
>>>>>> Option 1 can be problematic as often it is in reality the same =
`issuer` behind the scenes.
>>>>>>=20
>>>>>> We would like to get feedback on this issue and potentially an =
extension to RFC8414 to allow the definition of multiple authorization =
endpoints.
>>>>>>=20
>>>>>> Thanks in advance
>>>>>>=20
>>>>>> Dave Tonge
>>>>>> Co-Chair FAPI WG
>>>>>> Open ID Foundation
>>>>>>=20
>>>>>>=20
>>> --=20
>>> Vladimir Dzhuvinov
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

> --=20
> Vladimir Dzhuvinov


--Apple-Mail=_6C5A7A34-4C3C-4CD5-BE03-C994FB9778F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks Vladimir/Torsten.

I agree, it would make sense to have =
some form of static id for each entry. My first attempt started out =
similar but for some reason I decided to simplify=E2=80=A6

On the conceptual side =
for choosers (and biased towards how the UK openbanking ecosystem works =
as that=E2=80=99s what I know best), what this allows for is:

client chooser -> =
authorisation endpoint

Where the list is:

=E2=80=9CBank a=E2=80=9D
=E2=80=9CLoadsamoney personal=E2=80=9D
=E2=80=9CLoadsamoney business=E2=80=9D
=E2=80=9CBank c"


Instead of the only =
=E2=80=99standards compliant=E2=80=99 way to do app2app in this case =
today of:

client=
 chooser -> AS interstitial chooser on authorization endpoint -> =
real authorization endpoint

Where the first chooser is:

=E2=80=9CBank =
a=E2=80=9D
=E2=80=9CLoadsamoney=E2=80=9D
=E2=80=9CBank c=E2=80=9D

And the second:

=E2=80=9CPersonal"
=E2=80=9CBusiness"

The first case is much better, =
particularly for the real multi-brand case where the end user might not =
even associate the two bank brandnames with each other.

What actually happens =
today is the first case (single RP chooser), but based on banks emailing =
around lists of alternative authorization endpoints to the RP, or =
publishing the details on obscure developer portals - which destroys =
much of the convenience / agility / security the server metadata RFC was =
trying achieve.

The issue of how the RP finds the server metadata document is =
unchanged from today. (In the UK, we have a centralised directory that =
lists them.)

Joseph


On 22 May 2020, at 08:52, Vladimir Dzhuvinov =
<vladimir@connect2id.com> wrote:


 =20
    
 =20
  
With that said it makes sense to devise =
a structure which can
      accommodate UI driven as well as automatic choice.

    
    
      
  • The UI driven chooser will need a human readable =
description
        and other UI hints. This can work for instance with "classic"
        OIDC Discovery.
    
        
    
      
    • 
      
  • The "auto" chooser will need some sort of an ID. =
For a bank
        chooser this means providing the issuer URI and an optional
        brand ID and both must get registered together. Or, one could
        define a standard brand ID (label) for banking operations and if
        the "alternative_authorization_endpoints" is present look for it
        in the structure, else fall back to the default
        "authorization_endpoint".
      
    • 
    
Here is one possible layout which has IDs and UI =
hints:

    

    
{
  ...
  "alternative_authorization_endpoints": {
    "banking": {
      "authorization_endpoint": "https://loadsamoney/business/a=
uth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/busine=
ss/logo.png"
    },
    "personal": {
      "authorization_endpoint": "https://loadsamoney/consumer/a=
uth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consum=
er/logo.png"
    }
  }
}


    

    
On 22/05/2020 09:59, Torsten
      Lodderstedt wrote:

    

    

      
I think an id or label per =
endpoint set would be needed to determine the set of endpoints to be =
used by a certain client.

On the conceptual side, I=E2=80=99m asking myself how the complete =
process is supposed to work. Who is deciding what issuer/endpoint set =
combination to use. I assume in an open banking scenario, there will =
always be some kind of bank chooser. Will this chooser provide the =
client with issuer and brand id?=20



      

        
On 22. May 2020, at =
08:10, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

A mapping like the one you propose can definitely work. Since the user =
will be making the choice which endpoint to take with the client app, =
having the logo_uri is a good idea. If the branded endpoints differ =
somehow in policy one could also allow inclusion of the op_policy_uri =
and op_tos_uri params from Discovery.

https://openid.net/specs/openid-connect-discovery-1_0.html#Issue=
rDiscovery

Vladimir

On 20/05/2020 19:16, Joseph Heenan wrote:


        

          
Thanks for your =
thoughts Vladimir!

The client_id based solution I wasn=E2=80=99t previously aware of - =
unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile OS selects the app to use based purely on the URL (and in at =
least the iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).

I think some kind of mapping like you suggest will work and fallback, I =
wonder about a structure in the authorization server metadata something =
like this:

{
  ...
  "alternative_authorization_endpoints": [
    {
      "authorization_endpoint": "https://loadsamoney/business/a=
uth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/busine=
ss/logo.png"
    },
    {
      "authorization_endpoint": "https://loadsamoney/consumer/a=
uth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consum=
er/logo.png"
    }
  ]
}

And as you say, the existing authorization_endpoint can be a fallback =
for clients that are unaware of the new spec or prefer the simpler =
option of just using a single authorization endpoint. Supporting the new =
spec would allow a better UX though so there=E2=80=99s advantages to =
client to do so.


          

            
Speaking of mTLS, I'm =
not sure how the "mtls_endpoint_aliases" can be sensibly combined with =
the proposed multi-brand spec.



          

          
I think that particular =
part is not really an issue as mtls isn=E2=80=99t used at the =
authorization endpoint.

Thanks

Joseph




          

            
On 20 May 2020, at =
16:07, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

Hi Dave,

In the absence of such a "multi-brand" spec we have tackled this issue =
in the past by letting the "brand" be encoded in the client_id. An =
alternative scenario is to do a "brand" lookup by client_id. Then let =
the AS render the "branded" authZ endpoint.

You're probably aware the mTLS spec is allowing for endpoint aliases, so =
this is not the first time such as need has occurred:

https://tools.ietf.=
org/html/rfc8705#section-5

One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".

Clients that are aware of the new spec will look it up, those that are =
not will fall back to the std "authorization_endpoint".

Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be =
sensibly combined with the proposed multi-brand spec.



Vladimir



On 20/05/2020 15:07, Dave Tonge wrote:


            

              
Dear OAuth WG

We have an issue in the OpenID FAPI Working Group that we believe =
affects the wider OAuth community.

In summary: what is the recommended approach to discovery (RFC8414) for =
Authorization Servers who support multiple "brands" .

If brands are completely separate, then it seems sensible that each =
brand must have its own `issuer` and therefore its own discovery =
document at the correct location (i.e. brand 1 would have an issuer of =
"https://as/brand1" and a discovery =
document available at  https://=
as/.well-known/oauth-authorization-server/brand1).

However in the real world it is not always so simple. We have many =
existing implementations in UK open banking that support multiple =
authorization endpoints. Here is an example (thanks to @Joseph Heenan )



              

                
Bank =
=E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet banking, one =
=E2=80=9Clogin page=E2=80=9D for both business and personal customers.


              

              

              

                
They have =
separate mobile apps for business/personal, and are required to support =
app2app. This means they will definitely be exposing multiple =
authorization endpoints (as there=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.


              

              

              

                
Their choices =
are:


              

              

              

                
1. Multiple =
discovery endpoints (one for business, one for personal), each with a =
different authorization endpoint, multiple issuers (if their vendor =
allows this)
2. Single discovery endpoint, single issuer, multiple authorization =
endpoints listed in one discovery doc (one for business, one for =
personal) some of which are hardcoded by the 3rd party
3. Multiple discovery endpoints each with a different authorization =
endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)


              

              
Option 3 is invalid =
and that leaves us with options 1 and 2.=20
Option 1 can be problematic as often it is in reality the same `issuer` =
behind the scenes.

We would like to get feedback on this issue and potentially an extension =
to RFC8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG
Open ID Foundation




            

            

          

          

        

        
--=20
Vladimir Dzhuvinov

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


      

      

    

    
--=20
Vladimir Dzhuvinov

  




=

--Apple-Mail=_6C5A7A34-4C3C-4CD5-BE03-C994FB9778F3--


From nobody Fri May 22 01:35:07 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C5E3A0747 for ; Fri, 22 May 2020 01:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAJ3K4hAGSbh for ; Fri, 22 May 2020 01:35:01 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2413A0764 for ; Fri, 22 May 2020 01:35:00 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id t8so3908943wmi.0 for ; Fri, 22 May 2020 01:35:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OBkWujec2HI8t9+fXqGFhZkbrhWhgkJIA+I1WowJH60=; b=ZhTk8mHJhgdykNHpRUeUnJtqIYboGUoK6CvUH1t3vGYQ85Ht+1hGMoN8zcNsy5YfWl D6KP5DOl/c1ZHnTvfLPYipZ7aP4eqrQgxYeAweI/goRW30NzCqql+WTwCF92swWf4Sqn qatuaIPpK2uHYPwHS/f9smpXOmYDD4zGLG2vub6ba3lWuCfakDxTV77+Rh+5OgXHvWYJ XQPNZU9BNoDBHzsmgQ18OJihzGGBCwJrjxSgdOLmCJ4a4eyesp9T8ZS6K74Unut6Nb9D XonjNq37jnSEqQKZKv2JTSWQZxMpDFIlgHXwyTlp7Ud1HiS4sfg6s2Hd630HHouCxzcD V+uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OBkWujec2HI8t9+fXqGFhZkbrhWhgkJIA+I1WowJH60=; b=Zb6fGG3vgAafiPn9Vj05B716yGODeWdrWsYOGnAKSz5Jr3jbKVXqgiTvEibZaK8vnH G2z3jXC9plLp9i64d0sfV/1sCchcZek8pZFj3pwJay0KPj0Sfs7sr96tnaCkp6webQsT 9R4/QtBOt5mI4Lq0KUhZ4oywb35WM7HRQ+c0xG9ruQbzVtowjamcKMBkfPD6hCqZW31N Rkdky0+ahvjd8wEkO+LbEOYc3reqBzZDjKODOoNb2GQIvNomAnnnu3rCuU6XbqxSBK5T 49qM3rlrlHu0zlQDM6QrlVz6q6D/PxRLbkRo5mxzfKmYnotiGHn7n1x9pfBCikwpmwuj gKjw==
X-Gm-Message-State: AOAM530vlHDCBGcFQ799uMc0DDqb2tmFGviMqgpfSBZjuluJL7pqNGGD bNoWUjBtUOf4oYKDSVu1cj2svQ==
X-Google-Smtp-Source: ABdhPJxuRXI8RRkuTOIgW4G0pmT9VadkuShLeZdYPNiv6X3udCagQelQ4fDZZQW7/yttov7qsf06nQ==
X-Received: by 2002:a05:600c:290f:: with SMTP id i15mr12619013wmd.153.1590136497445;  Fri, 22 May 2020 01:34:57 -0700 (PDT)
Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id v126sm9560023wmb.4.2020.05.22.01.34.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 01:34:56 -0700 (PDT)
From: Joseph Heenan 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_77E6ADDF-C887-4F28-8E95-42AF7186D4DE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 22 May 2020 09:34:56 +0100
In-Reply-To: <66FD701A-6036-4D6E-A2AB-E206A0043BBF@authlete.com>
Cc: Torsten Lodderstedt , Openid-specs-fapi , oauth 
To: Vladimir Dzhuvinov 
References:  <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com> <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net> <99394ea7-4588-5a5e-6997-bb96a19a1196@connect2id.com> <66FD701A-6036-4D6E-A2AB-E206A0043BBF@authlete.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 May 2020 08:35:06 -0000

--Apple-Mail=_77E6ADDF-C887-4F28-8E95-42AF7186D4DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I just realised that =E2=80=9Cclient chooser=E2=80=9D in the below is a =
very ambiguous term.

Please read it to mean =E2=80=9Ca chooser presented by the client=E2=80=9D=
. (And in the UK today, that chooser is manually populated by the client =
developer based on the central directory.)

Joseph

> On 22 May 2020, at 09:32, Joseph Heenan  wrote:
>=20
> Thanks Vladimir/Torsten.
>=20
> I agree, it would make sense to have some form of static id for each =
entry. My first attempt started out similar but for some reason I =
decided to simplify=E2=80=A6
>=20
> On the conceptual side for choosers (and biased towards how the UK =
openbanking ecosystem works as that=E2=80=99s what I know best), what =
this allows for is:
>=20
> client chooser -> authorisation endpoint
>=20
> Where the list is:
>=20
> =E2=80=9CBank a=E2=80=9D
> =E2=80=9CLoadsamoney personal=E2=80=9D
> =E2=80=9CLoadsamoney business=E2=80=9D
> =E2=80=9CBank c"
>=20
>=20
> Instead of the only =E2=80=99standards compliant=E2=80=99 way to do =
app2app in this case today of:
>=20
> client chooser -> AS interstitial chooser on authorization endpoint -> =
real authorization endpoint
>=20
> Where the first chooser is:
>=20
> =E2=80=9CBank a=E2=80=9D
> =E2=80=9CLoadsamoney=E2=80=9D
> =E2=80=9CBank c=E2=80=9D
>=20
> And the second:
>=20
> =E2=80=9CPersonal"
> =E2=80=9CBusiness"
>=20
> The first case is much better, particularly for the real multi-brand =
case where the end user might not even associate the two bank brandnames =
with each other.
>=20
> What actually happens today is the first case (single RP chooser), but =
based on banks emailing around lists of alternative authorization =
endpoints to the RP, or publishing the details on obscure developer =
portals - which destroys much of the convenience / agility / security =
the server metadata RFC was trying achieve.
>=20
> The issue of how the RP finds the server metadata document is =
unchanged from today. (In the UK, we have a centralised directory that =
lists them.)
>=20
> Joseph
>=20
>=20
>=20
>> On 22 May 2020, at 08:52, Vladimir Dzhuvinov > wrote:
>>=20
>> With that said it makes sense to devise a structure which can =
accommodate UI driven as well as automatic choice.
>>=20
>> The UI driven chooser will need a human readable description and =
other UI hints. This can work for instance with "classic" OIDC =
Discovery.
>>=20
>> The "auto" chooser will need some sort of an ID. For a bank chooser =
this means providing the issuer URI and an optional brand ID and both =
must get registered together. Or, one could define a standard brand ID =
(label) for banking operations and if the =
"alternative_authorization_endpoints" is present look for it in the =
structure, else fall back to the default "authorization_endpoint".
>> Here is one possible layout which has IDs and UI hints:
>>=20
>> {
>>   ...
>>   "alternative_authorization_endpoints": {
>>     "banking": {
>>       "authorization_endpoint": "https://loadsamoney/business/auth" =
,
>>       "description": "loadsmoney business banking customers",
>>       "logo_url": "https://loadsamoney/business/logo.png" =

>>     },
>>     "personal": {
>>       "authorization_endpoint": "https://loadsamoney/consumer/auth" =
,
>>       "description": "loadsmoney personal customers",
>>       "logo_url": "https://loadsamoney/consumer/logo.png" =

>>     }
>>   }
>> }
>>=20
>>=20
>> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>>> I think an id or label per endpoint set would be needed to determine =
the set of endpoints to be used by a certain client.
>>>=20
>>> On the conceptual side, I=E2=80=99m asking myself how the complete =
process is supposed to work. Who is deciding what issuer/endpoint set =
combination to use. I assume in an open banking scenario, there will =
always be some kind of bank chooser. Will this chooser provide the =
client with issuer and brand id?=20
>>>=20
>>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov =
  wrote:
>>>>=20
>>>> A mapping like the one you propose can definitely work. Since the =
user will be making the choice which endpoint to take with the client =
app, having the logo_uri is a good idea. If the branded endpoints differ =
somehow in policy one could also allow inclusion of the op_policy_uri =
and op_tos_uri params from Discovery.
>>>>=20
>>>> =
https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery=
 =

>>>>=20
>>>> Vladimir
>>>>=20
>>>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>>>> Thanks for your thoughts Vladimir!
>>>>>=20
>>>>> The client_id based solution I wasn=E2=80=99t previously aware of =
- unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile OS selects the app to use based purely on the URL (and in at =
least the iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).
>>>>>=20
>>>>> I think some kind of mapping like you suggest will work and =
fallback, I wonder about a structure in the authorization server =
metadata something like this:
>>>>>=20
>>>>> {
>>>>>   ...
>>>>>   "alternative_authorization_endpoints": [
>>>>>     {
>>>>>       "authorization_endpoint": =
"https://loadsamoney/business/auth" ,
>>>>>       "description": "loadsmoney business banking customers",
>>>>>       "logo_url": "https://loadsamoney/business/logo.png" =

>>>>>     },
>>>>>     {
>>>>>       "authorization_endpoint": =
"https://loadsamoney/consumer/auth" ,
>>>>>       "description": "loadsmoney personal customers",
>>>>>       "logo_url": "https://loadsamoney/consumer/logo.png" =

>>>>>     }
>>>>>   ]
>>>>> }
>>>>>=20
>>>>> And as you say, the existing authorization_endpoint can be a =
fallback for clients that are unaware of the new spec or prefer the =
simpler option of just using a single authorization endpoint. Supporting =
the new spec would allow a better UX though so there=E2=80=99s =
advantages to client to do so.
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" =
can be sensibly combined with the proposed multi-brand spec.
>>>>>>=20
>>>>> I think that particular part is not really an issue as mtls =
isn=E2=80=99t used at the authorization endpoint.
>>>>>=20
>>>>> Thanks
>>>>>=20
>>>>> Joseph
>>>>>=20
>>>>>=20
>>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov =
  wrote:
>>>>>>=20
>>>>>> Hi Dave,
>>>>>>=20
>>>>>> In the absence of such a "multi-brand" spec we have tackled this =
issue in the past by letting the "brand" be encoded in the client_id. An =
alternative scenario is to do a "brand" lookup by client_id. Then let =
the AS render the "branded" authZ endpoint.
>>>>>>=20
>>>>>> You're probably aware the mTLS spec is allowing for endpoint =
aliases, so this is not the first time such as need has occurred:
>>>>>>=20
>>>>>> https://tools.ietf.org/html/rfc8705#section-5 =

>>>>>>=20
>>>>>> One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".
>>>>>>=20
>>>>>> Clients that are aware of the new spec will look it up, those =
that are not will fall back to the std "authorization_endpoint".
>>>>>>=20
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" =
can be sensibly combined with the proposed multi-brand spec.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Vladimir
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
>>>>>>> Dear OAuth WG
>>>>>>>=20
>>>>>>> We have an issue in the OpenID FAPI Working Group that we =
believe affects the wider OAuth community.
>>>>>>>=20
>>>>>>> In summary: what is the recommended approach to discovery =
(RFC8414) for Authorization Servers who support multiple "brands" .
>>>>>>>=20
>>>>>>> If brands are completely separate, then it seems sensible that =
each brand must have its own `issuer` and therefore its own discovery =
document at the correct location (i.e. brand 1 would have an issuer of =
"https://as/brand1"  and a discovery document =
available at  https://as/.well-known/oauth-authorization-server/brand1 =
).
>>>>>>>=20
>>>>>>> However in the real world it is not always so simple. We have =
many existing implementations in UK open banking that support multiple =
authorization endpoints. Here is an example (thanks to @Joseph Heenan )
>>>>>>>=20
>>>>>>>> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for =
internet banking, one =E2=80=9Clogin page=E2=80=9D for both business and =
personal customers.
>>>>>>>> They have separate mobile apps for business/personal, and are =
required to support app2app. This means they will definitely be exposing =
multiple authorization endpoints (as there=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.
>>>>>>>> Their choices are:
>>>>>>>> 1. Multiple discovery endpoints (one for business, one for =
personal), each with a different authorization endpoint, multiple =
issuers (if their vendor allows this)
>>>>>>>> 2. Single discovery endpoint, single issuer, multiple =
authorization endpoints listed in one discovery doc (one for business, =
one for personal) some of which are hardcoded by the 3rd party
>>>>>>>> 3. Multiple discovery endpoints each with a different =
authorization endpoint, same issuer in all cases (breaks RFC8414 and =
OIDC Discovery)
>>>>>>> Option 3 is invalid and that leaves us with options 1 and 2.=20
>>>>>>> Option 1 can be problematic as often it is in reality the same =
`issuer` behind the scenes.
>>>>>>>=20
>>>>>>> We would like to get feedback on this issue and potentially an =
extension to RFC8414 to allow the definition of multiple authorization =
endpoints.
>>>>>>>=20
>>>>>>> Thanks in advance
>>>>>>>=20
>>>>>>> Dave Tonge
>>>>>>> Co-Chair FAPI WG
>>>>>>> Open ID Foundation
>>>>>>>=20
>>>>>>>=20
>>>> --=20
>>>> Vladimir Dzhuvinov
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth =

>> --=20
>> Vladimir Dzhuvinov
>=20


--Apple-Mail=_77E6ADDF-C887-4F28-8E95-42AF7186D4DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
just realised that =E2=80=9Cclient chooser=E2=80=9D in the below is a =
very ambiguous term.

Please read it to mean =E2=80=9Ca chooser presented by the =
client=E2=80=9D. (And in the UK today, that chooser is manually =
populated by the client developer based on the central directory.)

Joseph

On 22 =
May 2020, at 09:32, Joseph Heenan <Joseph@authlete.com>=
 wrote:

Thanks =
Vladimir/Torsten.

I =
agree, it would make sense to have some form of static id for each =
entry. My first attempt started out similar but for some reason I =
decided to simplify=E2=80=A6

On the conceptual side for choosers =
(and biased towards how the UK openbanking ecosystem works as that=E2=80=99=
s what I know best), what this allows for is:

client chooser -> authorisation =
endpoint

Where =
the list is:

=E2=80=9CBank a=E2=80=9D
=E2=80=9CLoadsamo=
ney personal=E2=80=9D
=E2=80=9CLoadsamoney =
business=E2=80=9D
=E2=80=9CBank c"


Instead of the only =E2=80=99standards compliant=E2=80=99 way =
to do app2app in this case today of:

client chooser -> AS interstitial =
chooser on authorization endpoint -> real authorization =
endpoint

Where =
the first chooser is:

=E2=80=9CBank a=E2=80=9D
<=
div class=3D"">=E2=80=9CLoadsamoney=E2=80=9D
=E2=80=9C=
Bank c=E2=80=9D

And the second:

=E2=80=9CPersonal"
=E2=80=9CBusiness"

The first case is =
much better, particularly for the real multi-brand case where the end =
user might not even associate the two bank brandnames with each =
other.

What =
actually happens today is the first case (single RP chooser), but based =
on banks emailing around lists of alternative authorization endpoints to =
the RP, or publishing the details on obscure developer portals - which =
destroys much of the convenience / agility / security the server =
metadata RFC was trying achieve.

The issue of how the RP finds the =
server metadata document is unchanged from today. (In the UK, we have a =
centralised directory that lists them.)

Joseph



On 22 May 2020, at 08:52, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  
With that said it makes sense to devise =
a structure which can
      accommodate UI driven as well as automatic choice.

    
    
      
  • The UI driven chooser will need a human readable =
description
        and other UI hints. This can work for instance with "classic"
        OIDC Discovery.
    
        
    
      
    • 
      
  • The "auto" chooser will need some sort of an ID. =
For a bank
        chooser this means providing the issuer URI and an optional
        brand ID and both must get registered together. Or, one could
        define a standard brand ID (label) for banking operations and if
        the "alternative_authorization_endpoints" is present look for it
        in the structure, else fall back to the default
        "authorization_endpoint".
      
    • 
    
Here is one possible layout which has IDs and UI =
hints:

    

    
{
  ...
  "alternative_authorization_endpoints": {
    "banking": {
      "authorization_endpoint": "https://loadsamoney/business/a=
uth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/busine=
ss/logo.png"
    },
    "personal": {
      "authorization_endpoint": "https://loadsamoney/consumer/a=
uth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consum=
er/logo.png"
    }
  }
}


    

    
On 22/05/2020 09:59, Torsten
      Lodderstedt wrote:

    

    

      
I think an id or label per =
endpoint set would be needed to determine the set of endpoints to be =
used by a certain client.

On the conceptual side, I=E2=80=99m asking myself how the complete =
process is supposed to work. Who is deciding what issuer/endpoint set =
combination to use. I assume in an open banking scenario, there will =
always be some kind of bank chooser. Will this chooser provide the =
client with issuer and brand id?=20



      

        
On 22. May 2020, at =
08:10, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

A mapping like the one you propose can definitely work. Since the user =
will be making the choice which endpoint to take with the client app, =
having the logo_uri is a good idea. If the branded endpoints differ =
somehow in policy one could also allow inclusion of the op_policy_uri =
and op_tos_uri params from Discovery.

https://openid.net/specs/openid-connect-discovery-1_0.html#Issue=
rDiscovery

Vladimir

On 20/05/2020 19:16, Joseph Heenan wrote:


        

          
Thanks for your =
thoughts Vladimir!

The client_id based solution I wasn=E2=80=99t previously aware of - =
unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile OS selects the app to use based purely on the URL (and in at =
least the iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).

I think some kind of mapping like you suggest will work and fallback, I =
wonder about a structure in the authorization server metadata something =
like this:

{
  ...
  "alternative_authorization_endpoints": [
    {
      "authorization_endpoint": "https://loadsamoney/business/a=
uth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/busine=
ss/logo.png"
    },
    {
      "authorization_endpoint": "https://loadsamoney/consumer/a=
uth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consum=
er/logo.png"
    }
  ]
}

And as you say, the existing authorization_endpoint can be a fallback =
for clients that are unaware of the new spec or prefer the simpler =
option of just using a single authorization endpoint. Supporting the new =
spec would allow a better UX though so there=E2=80=99s advantages to =
client to do so.


          

            
Speaking of mTLS, I'm =
not sure how the "mtls_endpoint_aliases" can be sensibly combined with =
the proposed multi-brand spec.



          

          
I think that particular =
part is not really an issue as mtls isn=E2=80=99t used at the =
authorization endpoint.

Thanks

Joseph




          

            
On 20 May 2020, at =
16:07, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

Hi Dave,

In the absence of such a "multi-brand" spec we have tackled this issue =
in the past by letting the "brand" be encoded in the client_id. An =
alternative scenario is to do a "brand" lookup by client_id. Then let =
the AS render the "branded" authZ endpoint.

You're probably aware the mTLS spec is allowing for endpoint aliases, so =
this is not the first time such as need has occurred:

https://tools.ietf.=
org/html/rfc8705#section-5

One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".

Clients that are aware of the new spec will look it up, those that are =
not will fall back to the std "authorization_endpoint".

Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be =
sensibly combined with the proposed multi-brand spec.



Vladimir



On 20/05/2020 15:07, Dave Tonge wrote:


            

              
Dear OAuth WG

We have an issue in the OpenID FAPI Working Group that we believe =
affects the wider OAuth community.

In summary: what is the recommended approach to discovery (RFC8414) for =
Authorization Servers who support multiple "brands" .

If brands are completely separate, then it seems sensible that each =
brand must have its own `issuer` and therefore its own discovery =
document at the correct location (i.e. brand 1 would have an issuer of =
"https://as/brand1" and a discovery =
document available at  https://=
as/.well-known/oauth-authorization-server/brand1).

However in the real world it is not always so simple. We have many =
existing implementations in UK open banking that support multiple =
authorization endpoints. Here is an example (thanks to @Joseph Heenan )



              

                
Bank =
=E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet banking, one =
=E2=80=9Clogin page=E2=80=9D for both business and personal customers.


              

              

              

                
They have =
separate mobile apps for business/personal, and are required to support =
app2app. This means they will definitely be exposing multiple =
authorization endpoints (as there=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.


              

              

              

                
Their choices =
are:


              

              

              

                
1. Multiple =
discovery endpoints (one for business, one for personal), each with a =
different authorization endpoint, multiple issuers (if their vendor =
allows this)
2. Single discovery endpoint, single issuer, multiple authorization =
endpoints listed in one discovery doc (one for business, one for =
personal) some of which are hardcoded by the 3rd party
3. Multiple discovery endpoints each with a different authorization =
endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)


              

              
Option 3 is invalid =
and that leaves us with options 1 and 2.=20
Option 1 can be problematic as often it is in reality the same `issuer` =
behind the scenes.

We would like to get feedback on this issue and potentially an extension =
to RFC8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG
Open ID Foundation




            

            

          

          

        

        
--=20
Vladimir Dzhuvinov

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


      

      

    

    
--=20
Vladimir Dzhuvinov

  





=

--Apple-Mail=_77E6ADDF-C887-4F28-8E95-42AF7186D4DE--


From nobody Fri May 22 01:38:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5A3A076F for ; Fri, 22 May 2020 01:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCPdFSYwIxYI for ; Fri, 22 May 2020 01:38:44 -0700 (PDT)
Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DD23A076C for ; Fri, 22 May 2020 01:38:43 -0700 (PDT)
Received: by mail-ej1-x643.google.com with SMTP id d7so12051677eja.7 for ; Fri, 22 May 2020 01:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JjnT6l67tClJwDST08PiqJWXpuZHjeWE4feaAIk2FJ8=; b=FoTiEx7W/17uLVM4wR5dLndD6goGjUAg/ewbn/QDSNSwDShg5Cl/WbbvXxkSJe5dag sxm3AqI9sO/mRh1HdpKktYXJjHt2X4eA4EumgZbPBNtYazqTydY6DJWfKwl++71VXPfd weYUaM4vEIilv5jMqjEc/J6J2pDduZcI8a1+6lz8GVa++E5hlQupUQ7hzIX1pktzR5He 3FweQapRX9/OOsnK08S11J/F8QLkETAMmA5SXAnZF+VwP0c3L8sq5WFSXL7WbOjqaQLD V+hh6MOGyV4YyxJYThheC1TjMUQZxJE3VTbt2c9UgT5IpmvA2OGlXRAlBYCNqOvIdYQs iUkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JjnT6l67tClJwDST08PiqJWXpuZHjeWE4feaAIk2FJ8=; b=Qg3ZR2eibcNZAYxxoaVt9TTspNgedPP7jlHT+2fLndGmHulPNaX2pf3zRYVvQt7nsJ yBUP9UJqGdo+bvPlgbh8mDVIxdFXuUGV/OwEOEGNPdouQjhheEmF7iBBOQ/vRAhg6xFS PQAYH+uEsDk0BaLT8ktI/Ak+e/prl4hZmg6ag04gef5Xdgb7YG5KLZjcBiayRkNMwUX8 5cXxPGmsOdFS6DlCWHsiUFMbeREOds7m/b/fmTY1VutK7O9Oo79uOKqksdiW5pClWY5W Z+rRYx7BDtz8SD/5j9EmL3tWkduI8U0WOsM62d+7nKbg10FBr02JJU+1+CVOJi7vuaZt Vpfg==
X-Gm-Message-State: AOAM533F4OY+nWNHEbZAgyKS0d8J+9AE+jXvN1SSynB3odgUpyVqqp7+ bNZt+qjtzFd1wc+BfklK13KSBw==
X-Google-Smtp-Source: ABdhPJwMT+0KNW+X1VbqmTH3tP7F04eVN9NxqvgNxGUZa7hNo8Xk7+20vk1DjH8y1nLfIikqT5Y0Hw==
X-Received: by 2002:a17:906:9719:: with SMTP id k25mr7338479ejx.411.1590136722234;  Fri, 22 May 2020 01:38:42 -0700 (PDT)
Received: from p200300eb8f3b3fc8904241d200c1eeb6.dip0.t-ipconnect.de (p200300eb8f3b3fc8904241d200c1eeb6.dip0.t-ipconnect.de. [2003:eb:8f3b:3fc8:9042:41d2:c1:eeb6]) by smtp.gmail.com with ESMTPSA id a13sm6391059eds.6.2020.05.22.01.38.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 01:38:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <66FD701A-6036-4D6E-A2AB-E206A0043BBF@authlete.com>
Date: Fri, 22 May 2020 10:38:40 +0200
Cc: Vladimir Dzhuvinov , Openid-specs-fapi , oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <11B2194A-0C5F-4D5D-BD82-2B070EA05622@lodderstedt.net>
References:  <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com> <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net> <99394ea7-4588-5a5e-6997-bb96a19a1196@connect2id.com> <66FD701A-6036-4D6E-A2AB-E206A0043BBF@authlete.com>
To: Joseph Heenan 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 May 2020 08:38:48 -0000

The first case looks better to me as well. It would require a chooser =
that provides both the issuer url and the brand id.=20

BTW: I would prefer a more generic term in order to facilitate other use =
cases. I think it could be useful to have a discriminator for selecting =
a set of endpoints. For example, an AS could then support different =
versions or flavours of OAuth/OpenID in the same deployment. Just =
thinking aloud :-)

> On 22. May 2020, at 10:32, Joseph Heenan  wrote:
>=20
> Thanks Vladimir/Torsten.
>=20
> I agree, it would make sense to have some form of static id for each =
entry. My first attempt started out similar but for some reason I =
decided to simplify=E2=80=A6
>=20
> On the conceptual side for choosers (and biased towards how the UK =
openbanking ecosystem works as that=E2=80=99s what I know best), what =
this allows for is:
>=20
> client chooser -> authorisation endpoint
>=20
> Where the list is:
>=20
> =E2=80=9CBank a=E2=80=9D
> =E2=80=9CLoadsamoney personal=E2=80=9D
> =E2=80=9CLoadsamoney business=E2=80=9D
> =E2=80=9CBank c"
>=20
>=20
> Instead of the only =E2=80=99standards compliant=E2=80=99 way to do =
app2app in this case today of:
>=20
> client chooser -> AS interstitial chooser on authorization endpoint -> =
real authorization endpoint
>=20
> Where the first chooser is:
>=20
> =E2=80=9CBank a=E2=80=9D
> =E2=80=9CLoadsamoney=E2=80=9D
> =E2=80=9CBank c=E2=80=9D
>=20
> And the second:
>=20
> =E2=80=9CPersonal"
> =E2=80=9CBusiness"
>=20
> The first case is much better, particularly for the real multi-brand =
case where the end user might not even associate the two bank brandnames =
with each other.
>=20
> What actually happens today is the first case (single RP chooser), but =
based on banks emailing around lists of alternative authorization =
endpoints to the RP, or publishing the details on obscure developer =
portals - which destroys much of the convenience / agility / security =
the server metadata RFC was trying achieve.
>=20
> The issue of how the RP finds the server metadata document is =
unchanged from today. (In the UK, we have a centralised directory that =
lists them.)
>=20
> Joseph
>=20
>=20
>=20
>> On 22 May 2020, at 08:52, Vladimir Dzhuvinov =
 wrote:
>>=20
>> With that said it makes sense to devise a structure which can =
accommodate UI driven as well as automatic choice.
>>=20
>> 	=E2=80=A2 The UI driven chooser will need a human readable =
description and other UI hints. This can work for instance with =
"classic" OIDC Discovery.
>>=20
>> 	=E2=80=A2 The "auto" chooser will need some sort of an ID. For a =
bank chooser this means providing the issuer URI and an optional brand =
ID and both must get registered together. Or, one could define a =
standard brand ID (label) for banking operations and if the =
"alternative_authorization_endpoints" is present look for it in the =
structure, else fall back to the default "authorization_endpoint".
>> Here is one possible layout which has IDs and UI hints:
>>=20
>> {
>>   ...
>>   "alternative_authorization_endpoints": {
>>     "banking": {
>>       "authorization_endpoint":=20
>> "https://loadsamoney/business/auth"
>> ,
>>       "description": "loadsmoney business banking customers",
>>       "logo_url":=20
>> "https://loadsamoney/business/logo.png"
>>=20
>>     },
>>     "personal": {
>>       "authorization_endpoint":=20
>> "https://loadsamoney/consumer/auth"
>> ,
>>       "description": "loadsmoney personal customers",
>>       "logo_url":=20
>> "https://loadsamoney/consumer/logo.png"
>>=20
>>     }
>>   }
>> }
>>=20
>>=20
>>=20
>> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>>> I think an id or label per endpoint set would be needed to determine =
the set of endpoints to be used by a certain client.
>>>=20
>>> On the conceptual side, I=E2=80=99m asking myself how the complete =
process is supposed to work. Who is deciding what issuer/endpoint set =
combination to use. I assume in an open banking scenario, there will =
always be some kind of bank chooser. Will this chooser provide the =
client with issuer and brand id?=20
>>>=20
>>>=20
>>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov =

>>>>  wrote:
>>>>=20
>>>> A mapping like the one you propose can definitely work. Since the =
user will be making the choice which endpoint to take with the client =
app, having the logo_uri is a good idea. If the branded endpoints differ =
somehow in policy one could also allow inclusion of the op_policy_uri =
and op_tos_uri params from Discovery.
>>>>=20
>>>>=20
>>>> =
https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery=

>>>>=20
>>>>=20
>>>> Vladimir
>>>>=20
>>>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>>>=20
>>>>> Thanks for your thoughts Vladimir!
>>>>>=20
>>>>> The client_id based solution I wasn=E2=80=99t previously aware of =
- unfortunately it doesn=E2=80=99t solve the problem for app2app, as the =
mobile OS selects the app to use based purely on the URL (and in at =
least the iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).
>>>>>=20
>>>>> I think some kind of mapping like you suggest will work and =
fallback, I wonder about a structure in the authorization server =
metadata something like this:
>>>>>=20
>>>>> {
>>>>>   ...
>>>>>   "alternative_authorization_endpoints": [
>>>>>     {
>>>>>       "authorization_endpoint":=20
>>>>> "https://loadsamoney/business/auth"
>>>>> ,
>>>>>       "description": "loadsmoney business banking customers",
>>>>>       "logo_url":=20
>>>>> "https://loadsamoney/business/logo.png"
>>>>>=20
>>>>>     },
>>>>>     {
>>>>>       "authorization_endpoint":=20
>>>>> "https://loadsamoney/consumer/auth"
>>>>> ,
>>>>>       "description": "loadsmoney personal customers",
>>>>>       "logo_url":=20
>>>>> "https://loadsamoney/consumer/logo.png"
>>>>>=20
>>>>>     }
>>>>>   ]
>>>>> }
>>>>>=20
>>>>> And as you say, the existing authorization_endpoint can be a =
fallback for clients that are unaware of the new spec or prefer the =
simpler option of just using a single authorization endpoint. Supporting =
the new spec would allow a better UX though so there=E2=80=99s =
advantages to client to do so.
>>>>>=20
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" =
can be sensibly combined with the proposed multi-brand spec.
>>>>>>=20
>>>>>>=20
>>>>> I think that particular part is not really an issue as mtls =
isn=E2=80=99t used at the authorization endpoint.
>>>>>=20
>>>>> Thanks
>>>>>=20
>>>>> Joseph
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov =

>>>>>>  wrote:
>>>>>>=20
>>>>>> Hi Dave,
>>>>>>=20
>>>>>> In the absence of such a "multi-brand" spec we have tackled this =
issue in the past by letting the "brand" be encoded in the client_id. An =
alternative scenario is to do a "brand" lookup by client_id. Then let =
the AS render the "branded" authZ endpoint.
>>>>>>=20
>>>>>> You're probably aware the mTLS spec is allowing for endpoint =
aliases, so this is not the first time such as need has occurred:
>>>>>>=20
>>>>>>=20
>>>>>> https://tools.ietf.org/html/rfc8705#section-5
>>>>>>=20
>>>>>>=20
>>>>>> One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".
>>>>>>=20
>>>>>> Clients that are aware of the new spec will look it up, those =
that are not will fall back to the std "authorization_endpoint".
>>>>>>=20
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" =
can be sensibly combined with the proposed multi-brand spec.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Vladimir
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
>>>>>>=20
>>>>>>> Dear OAuth WG
>>>>>>>=20
>>>>>>> We have an issue in the OpenID FAPI Working Group that we =
believe affects the wider OAuth community.
>>>>>>>=20
>>>>>>> In summary: what is the recommended approach to discovery =
(RFC8414) for Authorization Servers who support multiple "brands" .
>>>>>>>=20
>>>>>>> If brands are completely separate, then it seems sensible that =
each brand must have its own `issuer` and therefore its own discovery =
document at the correct location (i.e. brand 1 would have an issuer of=20=

>>>>>>> "https://as/brand1" and a discovery document available at  =
https://as/.well-known/oauth-authorization-server/brand1
>>>>>>> ).
>>>>>>>=20
>>>>>>> However in the real world it is not always so simple. We have =
many existing implementations in UK open banking that support multiple =
authorization endpoints. Here is an example (thanks to @Joseph Heenan )
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for =
internet banking, one =E2=80=9Clogin page=E2=80=9D for both business and =
personal customers.
>>>>>>>>=20
>>>>>>>> They have separate mobile apps for business/personal, and are =
required to support app2app. This means they will definitely be exposing =
multiple authorization endpoints (as there=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.
>>>>>>>>=20
>>>>>>>> Their choices are:
>>>>>>>>=20
>>>>>>>> 1. Multiple discovery endpoints (one for business, one for =
personal), each with a different authorization endpoint, multiple =
issuers (if their vendor allows this)
>>>>>>>> 2. Single discovery endpoint, single issuer, multiple =
authorization endpoints listed in one discovery doc (one for business, =
one for personal) some of which are hardcoded by the 3rd party
>>>>>>>> 3. Multiple discovery endpoints each with a different =
authorization endpoint, same issuer in all cases (breaks RFC8414 and =
OIDC Discovery)
>>>>>>>>=20
>>>>>>> Option 3 is invalid and that leaves us with options 1 and 2.=20
>>>>>>> Option 1 can be problematic as often it is in reality the same =
`issuer` behind the scenes.
>>>>>>>=20
>>>>>>> We would like to get feedback on this issue and potentially an =
extension to RFC8414 to allow the definition of multiple authorization =
endpoints.
>>>>>>>=20
>>>>>>> Thanks in advance
>>>>>>>=20
>>>>>>> Dave Tonge
>>>>>>> Co-Chair FAPI WG
>>>>>>> Open ID Foundation
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>> --=20
>>>> Vladimir Dzhuvinov
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> --=20
>> Vladimir Dzhuvinov
>>=20
>=20


From nobody Fri May 22 02:37:43 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312643A0B37 for ; Fri, 22 May 2020 02:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbnveuoplrxO for ; Fri, 22 May 2020 02:37:32 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8101F3A0ABD for ; Fri, 22 May 2020 02:37:30 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id hldT220074FMSmm03ldTn7; Fri, 22 May 2020 11:37:28 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 22 May 2020 11:37:28 +0200
X-ME-IP: 86.238.65.197
To: Benjamin Kaduk 
Cc: oauth@ietf.org, Vittorio Bertocci 
References:  <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu>
From: Denis 
Message-ID: 
Date: Fri, 22 May 2020 11:37:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200521200735.GL58497@kduck.mit.edu>
Content-Type: multipart/alternative; boundary="------------2DAAA3147719CAD194796CD5"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 May 2020 09:37:42 -0000

This is a multi-part message in MIME format.
--------------2DAAA3147719CAD194796CD5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Benjamin,
> On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
>> Since then, I questioned myself how a client would be able to request an
>> access token that would be
>> *strictly compliant with this Profile*.
> I don't understand why this is an interesting question to ask.  The access
> token and interpretation thereof is (AIUI) generally seen as an internal
> matter between AS and RS, with the client having no need to care about the
> specifics.

This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
_*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.

1) A client may wish to obtain an Access Token that corresponds to this 
Profile because, for example,
this document mandates the "sub" claim to be present". Hence, the 
content of the Access Token is not
totally "/an internal matter between AS and RS/".

However, I have not understood how a client could request an Access 
Token that corresponds to *_this_***Profile,
since there is no mandatory parameter in the request (both the "scope" 
parameter and the "resource" parameter are optional).

In the future, we could define _*another*_**Profile. Hence, there is the 
same question:  How could a client request an Access Token
that corresponds to *_that other_***Profile ?

2) When getting a JWT,  how can the client make sure that the access 
token it got is compliant with this Profile ?

RFC 8725 states in section 3.11 :

    3.11. Use Explicit Typing
    Sometimes, one kind of JWT can be confused for another. If a
    particular kind of JWT is subject to such confusion,
    that JWT can include an explicit JWT type value, and the validation
    rules can specify checking the type (...).
    Explicit JWT typing is accomplished by using the "typ" Header
    Parameter.

Wouldn't be wise to include an explicit JWT type value for JWTs 
conformant to this Profile ?

This relates to an email posted by Dominick Baier under the topic "JAR: 
JWT typ" on May 19 :

    This has been brought up before - but no response.

    Either I can’t find it - or it is missing. But is the setting the
    JWT typ explicitly mentioned somewhere?

Denis

> To my knowledge, this WG has not previously given guidance
> indicating that the client should be involved or specifics for how to do
> so, and I do not remember seeing WG agreement that this should change.
>
> -Ben



--------------2DAAA3147719CAD194796CD5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Benjamin,

    

      
On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:


      

        
Since then, I questioned myself how a client would be able to request an 
access token that would be
*strictly compliant with this Profile*.


      

      
I don't understand why this is an interesting question to ask.  The access
token and interpretation thereof is (AIUI) generally seen as an internal
matter between AS and RS, with the client having no need to care about the
specifics.  

    

    
This document is a Profile for OAuth 2.0 Access
      Tokens. It is not the Profile for all OAuth
      2.0 Access Tokens.

    
1) A client may wish to obtain an Access Token that corresponds
      to this Profile because, for example, 

      this document mandates the "sub" claim to be present". Hence, the
      content of the Access Token is not 

      totally "an internal matter between AS and RS".  

    

    
However, I have not understood how a client could request an
      Access Token that corresponds to this Profile,
      

      since there is no mandatory parameter in the request (both the
      "scope" parameter and the "resource" parameter are optional). 

    
In the future, we could define another Profile.
      Hence, there is the same question:  How could a client request an
      Access Token 

      that corresponds to that other Profile ?

    
2) When getting a JWT,  how can the client make sure that the
      access token it got is compliant with this Profile ?

    
RFC 8725 states in section 3.11 :

    

      
3.11. Use Explicit Typing 

        Sometimes, one kind of JWT can be confused for another. If a
        particular kind of JWT is subject to such confusion, 

        that JWT can include an explicit JWT type value, and the
        validation rules can specify checking the type (...). 

        Explicit JWT typing is accomplished by using the "typ" Header
        Parameter. 

      

    

    
Wouldn't be wise to include an explicit JWT type value for JWTs
      conformant to this Profile ?

    

    
This relates to an email posted by Dominick Baier under the topic
      "JAR: JWT typ" on May 19 :

    

    

      
This has
        been brought up before - but no response.

      


      

      
Either I
        can’t find it - or it is missing. But is the setting the JWT typ
        explicitly mentioned somewhere?

    

    
Denis

    

    

      
To my knowledge, this WG has not previously given guidance
indicating that the client should be involved or specifics for how to do
so, and I do not remember seeing WG agreement that this should change.

-Ben


    

    


    

  


--------------2DAAA3147719CAD194796CD5--


From nobody Fri May 22 20:27:29 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84363A0F19 for ; Fri, 22 May 2020 20:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwA2iqJWjFES for ; Fri, 22 May 2020 20:27:23 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725A03A0F18 for ; Fri, 22 May 2020 20:27:23 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id e1so12164853wrt.5 for ; Fri, 22 May 2020 20:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=Mccoe1POXW+4T+oCOxwmXcU/qZoh3WjDbSTP6oNn6ck=; b=cM7HiwC9Wm1FDj1Tl5aEHpWGH2YkQclwGiYmme7dzDKEepmRSv7DF/+Kobb3YP0KVQ VrAMILhTNntm+3ou1gZJeKU/EtwbRkNW7I0thL+gBtQJ09s2mDYMOuSfEz0XtQiDfygq B0TAegBRPoWLxrAGOLH6VuSH05T7vV4SmDAt0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Mccoe1POXW+4T+oCOxwmXcU/qZoh3WjDbSTP6oNn6ck=; b=ABX03dl28xWgsbA9OJqGbejCe4WktQRb178suNUe8tCu25U5gf8Nk6BizabSQMRZhQ mYWsSL1BilWwsYubDOI8qYgncOLCugIwc7bQDECqts6CBSlkGKW01s5SsnUljP4jJG8G nNYQPYaD46j7InBZZ/TttgXnARr2IOrswO4jafk+UBmk+f/hwMAE0+QpTQ8qv3ZeumGO zOcSaqYnS6cxYc4hNKrwylrpwWPjHIpDXDXYJwAdtXDT+XuBflG+xf0c4jdIpY9+lOck KvD4NH2HKZI1smcYTFAAu6MUoRvSRM4UzwiVHCu3JbCG6bwgLAo3V9SzX3k2h4Ca/dfu Qvfw==
X-Gm-Message-State: AOAM530UcNLkk2ihsu6JYytmBddtBL5UHqVOJzWatzthFTKQpzTLIoI9 iZHUh/B8tAP2ZwYgKW74Dip+hatxGjnOSVurVj5/9aAbKaM5/w==
X-Google-Smtp-Source: ABdhPJxbCQifwFFmOQvJTeLpvCXHK7C09uqPL7FhwVKsErtdzpo4n0vVyV0eVuyPjzXECwehxDjitnjrEvxGMhy3Y6I=
X-Received: by 2002:adf:f28f:: with SMTP id k15mr3187531wro.283.1590204411548;  Fri, 22 May 2020 20:26:51 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Francis Pouatcha 
Date: Fri, 22 May 2020 23:26:40 -0400
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000012266205a6485118"
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 May 2020 03:27:27 -0000

--00000000000012266205a6485118
Content-Type: text/plain; charset="UTF-8"

- I will go for Option 1 even if we have the same runtime instance
producing tokens under different issuer uris.
- Option 2 might expose security risk as many clients rely on the issuer to
associate the  token with authorization context. By no way shall a token
issued for "personal" be valid for "business". Therefore
considering the use of the same issuer here might lead to confusion at
the RP.
- In order to avoid confusion, AS must make sure each "brand"
uses separated key material to produce the token.

BTW:
The term brand as used in the context of most Open Banking initiatives
refers to entities consuming the Interface provided by TPPs (Third Party
Providers). TPPs play the roles of RPs in the oAuth2 context.

Unless I misunderstood this thread we are using a brand here to refer to an
AS virtual host (issuer-uri).

Going forward, we need to agree on choosing another term to refer to
issuers, and leave the term "Brand" for consumers of TPP-interfaces.

The core brand problem we will be facing in open banking is for having the
AS display the "consumer-brand" logo to the RO in the consent screen.

>
> >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov 
> wrote:
> >>
> >> With that said it makes sense to devise a structure which can
> accommodate UI driven as well as automatic choice.
> >>
> >>      ? The UI driven chooser will need a human readable description and
> other UI hints. This can work for instance with "classic" OIDC Discovery.
> >>
> >>      ? The "auto" chooser will need some sort of an ID. For a bank
> chooser this means providing the issuer URI and an optional brand ID and
> both must get registered together. Or, one could define a standard brand ID
> (label) for banking operations and if the
> "alternative_authorization_endpoints" is present look for it in the
> structure, else fall back to the default "authorization_endpoint".
> >> Here is one possible layout which has IDs and UI hints:
> >>
> >> {
> >>   ...
> >>   "alternative_authorization_endpoints": {
> >>     "banking": {
> >>       "authorization_endpoint":
> >> "https://loadsamoney/business/auth"
> >> ,
> >>       "description": "loadsmoney business banking customers",
> >>       "logo_url":
> >> "https://loadsamoney/business/logo.png"
> >>
> >>     },
> >>     "personal": {
> >>       "authorization_endpoint":
> >> "https://loadsamoney/consumer/auth"
> >> ,
> >>       "description": "loadsmoney personal customers",
> >>       "logo_url":
> >> "https://loadsamoney/consumer/logo.png"
> >>
> >>     }
> >>   }
> >> }
> >>
> >>
> >>
> >> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
> >>> I think an id or label per endpoint set would be needed to determine
> the set of endpoints to be used by a certain client.
> >>>
> >>> On the conceptual side, I?m asking myself how the complete process is
> supposed to work. Who is deciding what issuer/endpoint set combination to
> use. I assume in an open banking scenario, there will always be some kind
> of bank chooser. Will this chooser provide the client with issuer and brand
> id?
> >>>
> >>>
> >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> >>>>  wrote:
> >>>>
> >>>> A mapping like the one you propose can definitely work. Since the
> user will be making the choice which endpoint to take with the client app,
> having the logo_uri is a good idea. If the branded endpoints differ somehow
> in policy one could also allow inclusion of the op_policy_uri and
> op_tos_uri params from Discovery.
> >>>>
> >>>>
> >>>>
> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
> >>>>
> >>>>
> >>>> Vladimir
> >>>>
> >>>> On 20/05/2020 19:16, Joseph Heenan wrote:
> >>>>
> >>>>> Thanks for your thoughts Vladimir!
> >>>>>
> >>>>> The client_id based solution I wasn?t previously aware of -
> unfortunately it doesn?t solve the problem for app2app, as the mobile OS
> selects the app to use based purely on the URL (and in at least the iOS
> case will not offer the user a choice if multiple apps claim to handle the
> same url).
> >>>>>
> >>>>> I think some kind of mapping like you suggest will work and
> fallback, I wonder about a structure in the authorization server metadata
> something like this:
> >>>>>
> >>>>> {
> >>>>>   ...
> >>>>>   "alternative_authorization_endpoints": [
> >>>>>     {
> >>>>>       "authorization_endpoint":
> >>>>> "https://loadsamoney/business/auth"
> >>>>> ,
> >>>>>       "description": "loadsmoney business banking customers",
> >>>>>       "logo_url":
> >>>>> "https://loadsamoney/business/logo.png"
> >>>>>
> >>>>>     },
> >>>>>     {
> >>>>>       "authorization_endpoint":
> >>>>> "https://loadsamoney/consumer/auth"
> >>>>> ,
> >>>>>       "description": "loadsmoney personal customers",
> >>>>>       "logo_url":
> >>>>> "https://loadsamoney/consumer/logo.png"
> >>>>>
> >>>>>     }
> >>>>>   ]
> >>>>> }
> >>>>>
> >>>>> And as you say, the existing authorization_endpoint can be a
> fallback for clients that are unaware of the new spec or prefer the simpler
> option of just using a single authorization endpoint. Supporting the new
> spec would allow a better UX though so there?s advantages to client to do
> so.
> >>>>>
> >>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can
> be sensibly combined with the proposed multi-brand spec.
> >>>>>>
> >>>>>>
> >>>>> I think that particular part is not really an issue as mtls isn?t
> used at the authorization endpoint.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Joseph
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> >>>>>>  wrote:
> >>>>>>
> >>>>>> Hi Dave,
> >>>>>>
> >>>>>> In the absence of such a "multi-brand" spec we have tackled this
> issue in the past by letting the "brand" be encoded in the client_id. An
> alternative scenario is to do a "brand" lookup by client_id. Then let the
> AS render the "branded" authZ endpoint.
> >>>>>>
> >>>>>> You're probably aware the mTLS spec is allowing for endpoint
> aliases, so this is not the first time such as need has occurred:
> >>>>>>
> >>>>>>
> >>>>>> https://tools.ietf.org/html/rfc8705#section-5
> >>>>>>
> >>>>>>
> >>>>>> One could devise a similar JSON object with mappings "label" -
> "authorization_endpoint".
> >>>>>>
> >>>>>> Clients that are aware of the new spec will look it up, those that
> are not will fall back to the std "authorization_endpoint".
> >>>>>>
> >>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can
> be sensibly combined with the proposed multi-brand spec.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Vladimir
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
> >>>>>>
> >>>>>>> Dear OAuth WG
> >>>>>>>
> >>>>>>> We have an issue in the OpenID FAPI Working Group that we believe
> affects the wider OAuth community.
> >>>>>>>
> >>>>>>> In summary: what is the recommended approach to discovery
> (RFC8414) for Authorization Servers who support multiple "brands" .
> >>>>>>>
> >>>>>>> If brands are completely separate, then it seems sensible that
> each brand must have its own `issuer` and therefore its own discovery
> document at the correct location (i.e. brand 1 would have an issuer of
> >>>>>>> "https://as/brand1" and a discovery document available at
> https://as/.well-known/oauth-authorization-server/brand1
> >>>>>>> ).
> >>>>>>>
> >>>>>>> However in the real world it is not always so simple. We have many
> existing implementations in UK open banking that support multiple
> authorization endpoints. Here is an example (thanks to @Joseph Heenan )
> >>>>>>>
> >>>>>>>
> >>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking, one
> ?login page? for both business and personal customers.
> >>>>>>>>
> >>>>>>>> They have separate mobile apps for business/personal, and are
> required to support app2app. This means they will definitely be exposing
> multiple authorization endpoints (as there?s a 1:1 mapping of authorization
> endpoints to mobile apps) - the choice is how they do this.
> >>>>>>>>
> >>>>>>>> Their choices are:
> >>>>>>>>
> >>>>>>>> 1. Multiple discovery endpoints (one for business, one for
> personal), each with a different authorization endpoint, multiple issuers
> (if their vendor allows this)
> >>>>>>>> 2. Single discovery endpoint, single issuer, multiple
> authorization endpoints listed in one discovery doc (one for business, one
> for personal) some of which are hardcoded by the 3rd party
> >>>>>>>> 3. Multiple discovery endpoints each with a different
> authorization endpoint, same issuer in all cases (breaks RFC8414 and OIDC
> Discovery)
> >>>>>>>>
> >>>>>>> Option 3 is invalid and that leaves us with options 1 and 2.
> >>>>>>> Option 1 can be problematic as often it is in reality the same
> `issuer` behind the scenes.
> >>>>>>>
> >>>>>>> We would like to get feedback on this issue and potentially an
> extension to RFC8414 to allow the definition of multiple authorization
> endpoints.
> >>>>>>>
> >>>>>>> Thanks in advance
> >>>>>>>
> >>>>>>> Dave Tonge
> >>>>>>> Co-Chair FAPI WG
> >>>>>>> Open ID Foundation
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> --
> >>>> Vladimir Dzhuvinov
>
-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

--00000000000012266205a6485118
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


- I will go for Option 1 even if we have the same run=
time instance producing tokens under different=C2=A0issuer uris.
=
- Option 2 might expose security risk as many clients rely on the=C2=A0issu=
er to associate the=C2=A0 token with authorization context. By no way shall=
 a token issued for "personal" be valid for "business".=
 Therefore considering=C2=A0the=C2=A0use of the=C2=A0same issuer here might=
 lead to confusion at the=C2=A0RP.
- In order to avoid confusion,=
 AS must make=C2=A0sure each "brand" uses=C2=A0separated key mate=
rial to produce the token.

BTW:
The =
term brand as used in the context of most Open Banking initiatives refers t=
o entities consuming the Interface provided by TPPs (Third Party Providers)=
. TPPs play the roles of RPs in the oAuth2 context.

Unless I misunderstood this thread we are using a brand here to refer to =
an AS virtual host (issuer-uri).

Going forward, we=
 need=C2=A0to=C2=A0agree on choosing another term to refer to issuers, and =
leave the term "Brand" for consumers of TPP-interfaces.

The core brand problem we will be facing in open banking is=
 for having the AS display the "consumer-brand" logo to the RO in=
 the consent screen.


>> On 22 May 2020, at 08:52, Vladimir Dzhuvinov <vladimir@connect2id.com>=
 wrote:

>> 

>> With that said it makes sense to devise a structure which can acco=
mmodate UI driven as well as automatic choice.

>> 

>>=C2=A0 =C2=A0 =C2=A0 ? The UI driven chooser will need a human read=
able description and other UI hints. This can work for instance with "=
classic" OIDC Discovery.

>> 

>>=C2=A0 =C2=A0 =C2=A0 ? The "auto" chooser will need some =
sort of an ID. For a bank chooser this means providing the issuer URI and a=
n optional brand ID and both must get registered together. Or, one could de=
fine a standard brand ID (label) for banking operations and if the "al=
ternative_authorization_endpoints" is present look for it in the struc=
ture, else fall back to the default "authorization_endpoint".

>> Here is one possible layout which has IDs and UI hints:

>> 

>> {

>>=C2=A0 =C2=A0...

>>=C2=A0 =C2=A0"alternative_authorization_endpoints": {

>>=C2=A0 =C2=A0 =C2=A0"banking": {

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": 

>> "https://loadsamoney/business/auth"

>> ,

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmone=
y business banking customers",

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 

>> "https://loadsamoney/business/logo.png"<=
br>
>> 

>>=C2=A0 =C2=A0 =C2=A0},

>>=C2=A0 =C2=A0 =C2=A0"personal": {

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": 

>> "https://loadsamoney/consumer/auth"

>> ,

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmone=
y personal customers",

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 

>> "https://loadsamoney/consumer/logo.png"<=
br>
>> 

>>=C2=A0 =C2=A0 =C2=A0}

>>=C2=A0 =C2=A0}

>> }

>> 

>> 

>> 

>> On 22/05/2020 09:59, Torsten Lodderstedt wrote:

>>> I think an id or label per endpoint set would be needed to det=
ermine the set of endpoints to be used by a certain client.

>>> 

>>> On the conceptual side, I?m asking myself how the complete pro=
cess is supposed to work. Who is deciding what issuer/endpoint set combinat=
ion to use. I assume in an open banking scenario, there will always be some=
 kind of bank chooser. Will this chooser provide the client with issuer and=
 brand id? 

>>> 

>>> 

>>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov <vladimir@connect2id.c=
om>

>>>>=C2=A0 wrote:

>>>> 

>>>> A mapping like the one you propose can definitely work. Si=
nce the user will be making the choice which endpoint to take with the clie=
nt app, having the logo_uri is a good idea. If the branded endpoints differ=
 somehow in policy one could also allow inclusion of the op_policy_uri and =
op_tos_uri params from Discovery.

>>>> 

>>>> 

>>>> https://o=
penid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery

>>>> 

>>>> 

>>>> Vladimir

>>>> 

>>>> On 20/05/2020 19:16, Joseph Heenan wrote:

>>>> 

>>>>> Thanks for your thoughts Vladimir!

>>>>> 

>>>>> The client_id based solution I wasn?t previously aware=
 of - unfortunately it doesn?t solve the problem for app2app, as the mobile=
 OS selects the app to use based purely on the URL (and in at least the iOS=
 case will not offer the user a choice if multiple apps claim to handle the=
 same url).

>>>>> 

>>>>> I think some kind of mapping like you suggest will wor=
k and fallback, I wonder about a structure in the authorization server meta=
data something like this:

>>>>> 

>>>>> {

>>>>>=C2=A0 =C2=A0...

>>>>>=C2=A0 =C2=A0"alternative_authorization_endpoints&=
quot;: [

>>>>>=C2=A0 =C2=A0 =C2=A0{

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint=
": 

>>>>> "https://loadsamoney/business/auth&qu=
ot;

>>>>> ,

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": &qu=
ot;loadsmoney business banking customers",

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 

>>>>> "https://loadsamoney/business/logo.pn=
g"

>>>>> 

>>>>>=C2=A0 =C2=A0 =C2=A0},

>>>>>=C2=A0 =C2=A0 =C2=A0{

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint=
": 

>>>>> "https://loadsamoney/consumer/auth&qu=
ot;

>>>>> ,

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": &qu=
ot;loadsmoney personal customers",

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 

>>>>> "https://loadsamoney/consumer/logo.pn=
g"

>>>>> 

>>>>>=C2=A0 =C2=A0 =C2=A0}

>>>>>=C2=A0 =C2=A0]

>>>>> }

>>>>> 

>>>>> And as you say, the existing authorization_endpoint ca=
n be a fallback for clients that are unaware of the new spec or prefer the =
simpler option of just using a single authorization endpoint. Supporting th=
e new spec would allow a better UX though so there?s advantages to client t=
o do so.

>>>>> 

>>>>>> Speaking of mTLS, I'm not sure how the "m=
tls_endpoint_aliases" can be sensibly combined with the proposed multi=
-brand spec.

>>>>>> 

>>>>>> 

>>>>> I think that particular part is not really an issue as=
 mtls isn?t used at the authorization endpoint.

>>>>> 

>>>>> Thanks

>>>>> 

>>>>> Joseph

>>>>> 

>>>>> 

>>>>> 

>>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov <<=
a href=3D"mailto:vladimir@connect2id.com" target=3D"_blank">vladimir@connec=
t2id.com>

>>>>>>=C2=A0 wrote:

>>>>>> 

>>>>>> Hi Dave,

>>>>>> 

>>>>>> In the absence of such a "multi-brand" s=
pec we have tackled this issue in the past by letting the "brand"=
 be encoded in the client_id. An alternative scenario is to do a "bran=
d" lookup by client_id. Then let the AS render the "branded"=
 authZ endpoint.

>>>>>> 

>>>>>> You're probably aware the mTLS spec is allowin=
g for endpoint aliases, so this is not the first time such as need has occu=
rred:

>>>>>> 

>>>>>> 

>>>>>> https://tools.ietf.org/html/rf=
c8705#section-5

>>>>>> 

>>>>>> 

>>>>>> One could devise a similar JSON object with mappin=
gs "label" - "authorization_endpoint".

>>>>>> 

>>>>>> Clients that are aware of the new spec will look i=
t up, those that are not will fall back to the std "authorization_endp=
oint".

>>>>>> 

>>>>>> Speaking of mTLS, I'm not sure how the "m=
tls_endpoint_aliases" can be sensibly combined with the proposed multi=
-brand spec.

>>>>>> 

>>>>>> 

>>>>>> 

>>>>>> Vladimir

>>>>>> 

>>>>>> 

>>>>>> 

>>>>>> On 20/05/2020 15:07, Dave Tonge wrote:

>>>>>> 

>>>>>>> Dear OAuth WG

>>>>>>> 

>>>>>>> We have an issue in the OpenID FAPI Working Gr=
oup that we believe affects the wider OAuth community.

>>>>>>> 

>>>>>>> In summary: what is the recommended approach t=
o discovery (RFC8414) for Authorization Servers who support multiple "=
brands" .

>>>>>>> 

>>>>>>> If brands are completely separate, then it see=
ms sensible that each brand must have its own `issuer` and therefore its ow=
n discovery document at the correct location (i.e. brand 1 would have an is=
suer of 

>>>>>>> "https://as/brand1" and a discovery docu=
ment available at=C2=A0 https://as/.well-kno=
wn/oauth-authorization-server/brand1

>>>>>>> ).

>>>>>>> 

>>>>>>> However in the real world it is not always so =
simple. We have many existing implementations in UK open banking that suppo=
rt multiple authorization endpoints. Here is an example (thanks to @Joseph =
Heenan )

>>>>>>> 

>>>>>>> 

>>>>>>>> Bank ?loadsamoney? has one idp and, for in=
ternet banking, one ?login page? for both business and personal customers.<=
br>
>>>>>>>> 

>>>>>>>> They have separate mobile apps for busines=
s/personal, and are required to support app2app. This means they will defin=
itely be exposing multiple authorization endpoints (as there?s a 1:1 mappin=
g of authorization endpoints to mobile apps) - the choice is how they do th=
is.

>>>>>>>> 

>>>>>>>> Their choices are:

>>>>>>>> 

>>>>>>>> 1. Multiple discovery endpoints (one for b=
usiness, one for personal), each with a different authorization endpoint, m=
ultiple issuers (if their vendor allows this)

>>>>>>>> 2. Single discovery endpoint, single issue=
r, multiple authorization endpoints listed in one discovery doc (one for bu=
siness, one for personal) some of which are hardcoded by the 3rd party

>>>>>>>> 3. Multiple discovery endpoints each with =
a different authorization endpoint, same issuer in all cases (breaks RFC841=
4 and OIDC Discovery)

>>>>>>>> 

>>>>>>> Option 3 is invalid and that leaves us with op=
tions 1 and 2. 

>>>>>>> Option 1 can be problematic as often it is in =
reality the same `issuer` behind the scenes.

>>>>>>> 

>>>>>>> We would like to get feedback on this issue an=
d potentially an extension to RFC8414 to allow the definition of multiple a=
uthorization endpoints.

>>>>>>> 

>>>>>>> Thanks in advance

>>>>>>> 

>>>>>>> Dave Tonge

>>>>>>> Co-Chair FAPI WG

>>>>>>> Open ID Foundation

>>>>>>> 

>>>>>>> 

>>>>>>> 

>>>> -- 

>>>> Vladimir Dzhuvinov
-- 
<=
div>
Francis Pouatcha
=

Co-Founder and Technical Lead at adorys


--00000000000012266205a6485118--


From nobody Sat May 23 13:25:51 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819783A0BAB for ; Sat, 23 May 2020 13:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NG_J3btUP5E for ; Sat, 23 May 2020 13:25:47 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007343A08B6 for ; Sat, 23 May 2020 13:25:46 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04NKPXDX013610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 May 2020 16:25:36 -0400
Date: Sat, 23 May 2020 13:25:32 -0700
From: Benjamin Kaduk 
To: RFC Errata System 
Cc: n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com, naa@google.com, rdd@cert.org, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com, dmitry.khlebnikov@rea-group.com, oauth@ietf.org
Message-ID: <20200523202532.GE58497@kduck.mit.edu>
References: <20200518100426.ACC2DF40753@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200518100426.ACC2DF40753@rfc-editor.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 May 2020 20:25:50 -0000

Authors, WG, any comments?

Right now the likely dispositions seem to me to be Editorial/HFDU or
Rejected; the text is noting that salting is not used and attempting to
give an explanation of why that's the right choice.  It's not clear that
the WG was in error to include some such discussion at the time of
publication, which is essentially what this errata report is claiming.

Thanks,

Ben

On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7636,
> "Proof Key for Code Exchange by OAuth Public Clients".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6179
> 
> --------------------------------------
> Type: Technical
> Reported by: Dmitry Khlebnikov 
> 
> Section: 7.3
> 
> Original Text
> -------------
> 7.3.  Salting the code_challenge
> 
>    To reduce implementation complexity, salting is not used in the
>    production of the code challenge, as the code verifier contains
>    sufficient entropy to prevent brute-force attacks.  Concatenating a
>    publicly known value to a code verifier (containing 256 bits of
>    entropy) and then hashing it with SHA256 to produce a code challenge
>    would not increase the number of attempts necessary to brute force a
>    valid value for code verifier.
> 
>    While the "S256" transformation is like hashing a password, there are
>    important differences.  Passwords tend to be relatively low-entropy
>    words that can be hashed offline and the hash looked up in a
>    dictionary.  By concatenating a unique though public value to each
>    password prior to hashing, the dictionary space that an attacker
>    needs to search is greatly expanded.
> 
>    Modern graphics processors now allow attackers to calculate hashes in
>    real time faster than they could be looked up from a disk.  This
>    eliminates the value of the salt in increasing the complexity of a
>    brute-force attack for even low-entropy passwords.
> 
> Corrected Text
> --------------
> 
> 
> Notes
> -----
> The section misrepresents the information about "salting" and the whole idea 
> of "salting" is not applicable to a standalone hash.  I suggest to drop the entire
> section as irrelevant to the rest of the standard.
> 
> For some reason the section implies that "salting" is protecting and increasing
> entropy of a single hash, which is not what "salting" is about and is not the
> reason for the technique.  The section is also making a speculative assumptions
> about the low-entropy tendency in password hashes and makes an incorrect
> conclusion on the benefits of "salting" for a password hash.
> 
> One could argue that the entropy and the complexity required to bruteforce a hash
> and a salted hash for the same password (where the same hashing algorithm is
> applied) are approximately the same in most cases (or just slightly more
> complex for the salted version if the producer of the hash used a non-standard
> routine in relation of mixing in the salt, e.g. instead of appending the salt
> it inserts in in the middle of the password to be hashed).  In any case, that
> public data is already known to the attacker and it is just a matter of the
> configuration for the bruteforcing tool (such as JohnTheRipper) to incorporate
> the knowledge.
> 
> Just as an illustration: consider an example password ('abc'), an example salt
> ('123'), and that the hash is generated using a concatinated version of these
> two (e.g. HASH('abc123')).  Since the salt is included with the hash in plain
> text, the bruteforcer would just need to set their tool up with the "^.*123$"
> pattern making the salt essentially a string terminator which is not affecting
> the bruteforce effort in any way).
> 
> More and more people I meet are confused about the problem area the "salting"
> technique was invented to address: it is to increase the entropy of a set of
> passwords, so the same password would not result in the same hash value, with
> the primary goal is to prevent attackers to be able to re-use pre-calculated
> hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to
> make it impossible to quickly assess what hashes the attacker should focus on
> (e.g.  when you have 1000 hashes and without salts you can easily spot that
> some hashes are the same, which means breaking these one would gain much more
> in comparison to unique hashes in the same set).
> 
> This being said, I am suggesting to drop section 7.3 completely as irrelevant, 
> since what we currently have is very confusing and seeds unnecessary and
> wrong ideas that "salting" can improve the security of a single hash by itself.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7636 (draft-ietf-oauth-spop-15)
> --------------------------------------
> Title               : Proof Key for Code Exchange by OAuth Public Clients
> Publication Date    : September 2015
> Author(s)           : N. Sakimura, Ed., J. Bradley, N. Agarwal
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


From nobody Sat May 23 17:12:44 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76F3A0F81 for ; Sat, 23 May 2020 17:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMES6T0EY2ZS for ; Sat, 23 May 2020 17:12:40 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2048.outbound.protection.outlook.com [40.107.220.48]) (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 2E14C3A0CF3 for ; Sat, 23 May 2020 17:12:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vo+H4zOaNyglHnauPRD49MLJ3i87nvLIdvRjFrn/u8giSrXT5nCvNrd+2IpRw6t7YOYDlnciRsQXOxRiWQLZKGnbokHTWZD3fGUQMiT7fBJl+50qiwQoL6ViXhOlg3giORwWpNHalil3eukXck65d1BTz4c6+JpxrdGnEo3mHabu9b7rFyszk3nCk/6RzZTX5V7+u7ZaQp/9qlc5dmYKxP/Pq/6+3YoYZJiF+gjGa5v14Fv//Qe54dIGpy9o81tU1OWBSaS54WxZv1JkTi9/TwVsi5t01HqE+g8pVDnxSnMZJL8c+6dsd0tR10tC7HSuidryM6eS+g2/1tC58VlX5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=69PY4/94nILmbatkETk4Y0/UwCkOlGdrG5HTzd6N+wk=; b=LM1VJuABlaDjVT863yp7t2eZFX7KyXyWdgsWIoz7BSqdmfjYqbz0PPZCwH4C55KicYveHDOE/YXHf85kuu5SNPzn+ynrDXGFVBEUecKKt32FAixeIuCqNK+exEmXlelMxNmDjyQ00wndTS3BZpTrezy9GbKJ2rrsm3L9s8O9meUJdbSMkhb39IkK+I9a55lRFgdVaU4taT+sF1Z3pNdBp4/eFKPxt8MmOt1RgaZyDqb1p/vLDAXOniamdMRYl5lrgsZBZ/63tMOdJJX7fjWHmu7qliYkTAQt7T8KcNCWFqKtTd/NUR6NIwbfUYvxYB+p0PYyj1OyuGOH9LpKGJrnDA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adobe.com; dmarc=pass action=none header.from=adobe.com; dkim=pass header.d=adobe.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=69PY4/94nILmbatkETk4Y0/UwCkOlGdrG5HTzd6N+wk=; b=Sf2YHE99/i3lUvtI/5ICcCn7sbI2XhBRXyilXsH4rXGKoV6Livpy5RHeuKJ7NYaJC5w1+WePTkpsnehEFaL5LBChofQxHY+wBJ6bv42HaQWDqwk60NqPGlC2AV6txhQxIMmqxQx98w+B4PtMDOynU2+1/O+u2w+Y3odD9ZjEWpY=
Received: from BYAPR02MB5286.namprd02.prod.outlook.com (2603:10b6:a03:61::11) by BYAPR02MB4263.namprd02.prod.outlook.com (2603:10b6:a03:5b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Sun, 24 May 2020 00:12:38 +0000
Received: from BYAPR02MB5286.namprd02.prod.outlook.com ([fe80::517c:732:6e91:f8c1]) by BYAPR02MB5286.namprd02.prod.outlook.com ([fe80::517c:732:6e91:f8c1%3]) with mapi id 15.20.3021.026; Sun, 24 May 2020 00:12:38 +0000
From: Michael Thornburgh 
To: "oauth@ietf.org" 
Thread-Topic: oauth-adjacent: draft-thornburgh-fwk-dc-token-iss-00
Thread-Index: AQHWMWAIPO1WERV3eEqhvRz0LfK5pA==
Date: Sun, 24 May 2020 00:12:37 +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=adobe.com;
x-originating-ip: [2001:470:8192::2]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6600f966-bb35-4604-66c9-08d7ff772af1
x-ms-traffictypediagnostic: BYAPR02MB4263:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0413C9F1ED
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TH+4cDHIRrQWP6P4hj+zjSbOHYSLLQScyJVTF72opc/mMbb3kqsSp/KUtxjhh1ESB/as/hxVOu8t+OyDqKMuTO7A/fM3wYMiF+5JjaRWyHoVH5nJdPM9ej+tJAuVyWuumK7Tt8T+JRBXBaKSA2TJWtA+T4qEuGxMl7W4QfeGmWJCbcTVWmOxgyPHP2LW4QEtAZUGcJTkIvvVMPwkpFsBxzlyPxFuPl1PXqzQ/CPJuD3L+tNfCiHfC+B3uXrboCScDydv2gQvkhLIne/orzAXeg6ZIn77qfAHiMAgxl7fZ4TMkCEq3zQ7k29vrViiBT26DfyG7lqAP1nbVtIreCuF0zeWXaKgTbQYlIzxDnxpaqIPDlfv460vW/X/VegBQQ0w0RJcGBIrXAdXOnGF+HRXjA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BYAPR02MB5286.namprd02.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(86362001)(5660300002)(2906002)(8990500004)(33656002)(55016002)(6916009)(9686003)(66476007)(66946007)(76116006)(66556008)(66446008)(478600001)(64756008)(966005)(52536014)(8676002)(71200400001)(786003)(316002)(7696005)(8936002)(6506007)(186003); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: rc1Ygviu/4UGacuapIU/lY3wPM/JTniRjHeLOSETJ+Z6XBaoewijPuJRqlSwSXfYSuJY2YMUWF+fj3bWXv4beBH2Nd/a0SxhCxzr/MgDKNNYC20tKTLkB4KN2H3aIGPe43epSaB64kjbut8ONvpVFKl8KfzEwy4Q26hcrMdQ6nQ9/6esy7JpuzIkx+pbdmkNEBSDYETTtJl0ktdOpYagmMeLNiHWCorVpmu/CNusZACFcdwBVfPOm2tpZaa6JKclUHIVgV1J3kJSnuJq22/9gXX7AHUl+kFgyJ5lhqSPYIXT7dR94nUw6y1xkRgaI/U5RE31umx4u7TyX1iUKQ9SImxO9GQQB1IeLRdcOrkg7YoxbS7w2i2oeTwQkfECiwXT7OfCG7LZDsQRo1hCkT4pB1/WzwIcgaaFrjYII7yEjrXmv9MrZXmyDX+sRr3/LRjfD47IRyHvHDngVxFIt/rYfH2Sundldadqj4z5Sg8VRN9TCsJUmfnO3uiE76RI5lDp
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6600f966-bb35-4604-66c9-08d7ff772af1
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2020 00:12:37.9841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aka5+Bv0GTZuitpBInjDuPvl/tuMSLv1YhivNdjtTUkgqGMNbYG93I/X5XxRIZygeJmvT40zCe+24XeDIC3t8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4263
Archived-At: 
Subject: [OAUTH-WG] oauth-adjacent: draft-thornburgh-fwk-dc-token-iss-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 May 2020 00:12:43 -0000

hi WG.

i'd like to bring to your attention my OAuth-adjacent draft, draft-thornbur=
gh-fwk-dc-token-iss, for examination, comment, and maybe even consideration=
:

- title: A Framework For Decentralized Bearer Token Issuance in HTTP
- datatracker: https://datatracker.ietf.org/doc/draft-thornburgh-fwk-dc-tok=
en-iss/
- fancy-html: https://www.ietf.org/id/draft-thornburgh-fwk-dc-token-iss-00.=
html

TL;DR:
------
* bearer tokens are (still) appropriate, and even beneficial, for many use =
cases.

* OAuth has gaps (see for example TxAuth, draft-ietf-oauth-distributed), es=
pecially for the motivating case of decentralized identity systems and dece=
ntralized, independent RSes.

* this draft proposes a general form to support the motivating use case, bu=
t is applicable in other cases as well (including some of DPoP's).

the introduction section of the draft elaborates on the motivation and envi=
sioned use cases.

longer intro:
-------------
my proposal was initially motivated by semantic and security problems i saw=
 [1] in the Solid Project's [2] existing authentication system. that system=
 is based on WebID, OIDC, and proof-of-possession. it addresses the decentr=
alized identity problem (WebID + OIDC) and the decentralized, multiple, ind=
ependent RS problem, where neither the client nor the user's OpenID Provide=
r has prior knowledge of what RSes will be visited, and where the RS's auth=
orization infrastructure is not (necessarily) the user's OpenID Provider. t=
he system is especially intended to enable authenticated access without req=
uiring the user to log in separately to each RS. other than its problems [1=
] it's pretty cool.

my solution to the problems with Solid's existing system is (essentially) f=
or the client to be able to discover where and how to get a bearer token fr=
om a competent AS for a new RS it's visiting. initial versions (pre-I-D) [5=
][3] were very WebID-specific, but while developing it a more general solut=
ion emerged. reading through past messages in this WG, i think my approach =
may be of interest to some here. there is a superficial similarity to Jpop =
(in that there is a nonce in the WWW-Authenticate), but it is otherwise sub=
stantially different.

of particular note, at least one (but definitely not all) use cases for DPo=
P can also be addressed by this proposal. in particular, a client can prove=
 current possession of a POP key to obtain a reusable bearer token constrai=
ned to one origin+realm, for an independent and arbitrarily short lifetime.

i have an example/POC implementation of the "token_pop_endpoint" mechanism =
specifically for WebID and the Solid use case, in the form of an nginx ngx_=
auth_request_module, at [4].

full disclosure: at present the Solid Authentication Panel is leaning towar=
d an approach that uses substantially the same semantics as their current s=
ystem, but adapted to the syntax of DPoP. i am not in favor of this approac=
h, but i am in the minority.

this is long. thanks if you read this far.

-michael thornburgh


  [1]: https://github.com/solid/authentication-panel/issues/1
  [2]: https://solidproject.org/
  [3]: https://github.com/zenomt/webid-auth-protocol
  [4]: https://github.com/zenomt/webid-auth-nginx
  [5]: https://github.com/solid/webid-oidc-spec/issues/25


From nobody Sun May 24 14:37:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A393A0C63 for ; Sun, 24 May 2020 14:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4zQYIBMr-8z for ; Sun, 24 May 2020 14:37:34 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B653A0C59 for ; Sun, 24 May 2020 14:37:33 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id e1so15422357wrt.5 for ; Sun, 24 May 2020 14:37:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=rRHWJK/R7jkkh0SZkR/N91tulzAFlks2/69Ko/NFePI=; b=g8v6Lv9YNmABaAmrFpiy50h52Qq+TDipBxxF8wEc6ezC0J+y2k6clFgZDxgnZW+z7f B53W0S4o7RRvgxichDLlW9M6ER/6O+gJ0HzKhCzqPSYeE3WH84jUZIAz7JPqqWp43Kis A9s/x6sIrOJFi8y2+KRuZhyyUlrbmLik21lpw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rRHWJK/R7jkkh0SZkR/N91tulzAFlks2/69Ko/NFePI=; b=qJd9ZXILGD+r7R1xEuWuKUl6oxjMXVKZ55JMpjP7r++5lorjVKJNPldnomfvcqHnyd fHkvrbTw/+MG6G5E+QwoRGNNQAi6tx/zorI6FDBsKH0zlIiaucpRSnaV2NGQO7azuO9f KlmhswK9FQn3p1jFG2sw1CWDn2hHue6ROocpR4LGrDwrwafBlSXwld9o6A2P/1dQS4Ia seWEhYfopVXOymQawskdFZ0FyH4fn+HqRtXgxVUcH55+udeZUNMautMeuBlTSeXW9O7T pVJGLG3fmRD8X4WNA5/K5tr6A3I2jCOwgCVZeDkfhbEWo5mhoWGmZzgUdpze1SchcdUZ GONg==
X-Gm-Message-State: AOAM5327AJH7csidO1LsbRo41/qvyx4lS2qR5tnQLTTY3v5qBY5Q7iS3 KBg9mTF/sRjt4Q0dns3LuSpKKMyY1wcNmnqbDbR15Eqj47Uj1Q==
X-Google-Smtp-Source: ABdhPJyX2jEgHx4fDoDKeyOnMj8sjLieaT9PhgrbJ+YQHw+cZgYeoGC26z2IHo1pvIpnprxqE3hJD73GgWSHrPMlZaQ=
X-Received: by 2002:a5d:4bc5:: with SMTP id l5mr8959139wrt.104.1590356251360;  Sun, 24 May 2020 14:37:31 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Francis Pouatcha 
Date: Sun, 24 May 2020 17:37:20 -0400
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000006dd0ca05a66bab02"
Archived-At: 
Subject: Re: [OAUTH-WG] oauth-adjacent: draft-thornburgh-fwk-dc-token-iss-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 May 2020 21:37:37 -0000

--0000000000006dd0ca05a66bab02
Content-Type: text/plain; charset="UTF-8"

Hello Michael,

The proposal looks very promising.There is a need for a framework with an
even higher abstraction. Decentralized issuance of bearer token is
gaining space, as in the open banking ecosystem we witness Clients which
have to deal with many AS or "Mechanism Endpoint" like you call it in the
proposal.

In some situations, the "Mechanism Endpoint" can be  a device in the
possession of the resource owner (RO) and it initiates the original service
request to the Client and it is not open to receive a POST request. In
which case the "POST token request" in Figure 1 will be replaced by a 401
response to the "Mechanism Endpoint" that will in turn produce the bearer
token and resent it to the Client.

/Francis


>
> hi WG.
>
> i'd like to bring to your attention my OAuth-adjacent draft,
> draft-thornburgh-fwk-dc-token-iss, for examination, comment, and maybe even
> consideration:
>
> - title: A Framework For Decentralized Bearer Token Issuance in HTTP
> - datatracker:
> https://datatracker.ietf.org/doc/draft-thornburgh-fwk-dc-token-iss/
> - fancy-html:
> https://www.ietf.org/id/draft-thornburgh-fwk-dc-token-iss-00.html
>
> TL;DR:
> ------
> * bearer tokens are (still) appropriate, and even beneficial, for many use
> cases.
>
> * OAuth has gaps (see for example TxAuth, draft-ietf-oauth-distributed),
> especially for the motivating case of decentralized identity systems and
> decentralized, independent RSes.
>
> * this draft proposes a general form to support the motivating use case,
> but is applicable in other cases as well (including some of DPoP's).
>
> the introduction section of the draft elaborates on the motivation and
> envisioned use cases.
>
> longer intro:
> -------------
> my proposal was initially motivated by semantic and security problems i
> saw [1] in the Solid Project's [2] existing authentication system. that
> system is based on WebID, OIDC, and proof-of-possession. it addresses the
> decentralized identity problem (WebID + OIDC) and the decentralized,
> multiple, independent RS problem, where neither the client nor the user's
> OpenID Provider has prior knowledge of what RSes will be visited, and where
> the RS's authorization infrastructure is not (necessarily) the user's
> OpenID Provider. the system is especially intended to enable authenticated
> access without requiring the user to log in separately to each RS. other
> than its problems [1] it's pretty cool.
>
> my solution to the problems with Solid's existing system is (essentially)
> for the client to be able to discover where and how to get a bearer token
> from a competent AS for a new RS it's visiting. initial versions (pre-I-D)
> [5][3] were very WebID-specific, but while developing it a more general
> solution emerged. reading through past messages in this WG, i think my
> approach may be of interest to some here. there is a superficial similarity
> to Jpop (in that there is a nonce in the WWW-Authenticate), but it is
> otherwise substantially different.
>
> of particular note, at least one (but definitely not all) use cases for
> DPoP can also be addressed by this proposal. in particular, a client can
> prove current possession of a POP key to obtain a reusable bearer token
> constrained to one origin+realm, for an independent and arbitrarily short
> lifetime.
>
> i have an example/POC implementation of the "token_pop_endpoint" mechanism
> specifically for WebID and the Solid use case, in the form of an nginx
> ngx_auth_request_module, at [4].
>
> full disclosure: at present the Solid Authentication Panel is leaning
> toward an approach that uses substantially the same semantics as their
> current system, but adapted to the syntax of DPoP. i am not in favor of
> this approach, but i am in the minority.
>
> this is long. thanks if you read this far.
>
> -michael thornburgh
>
>
>   [1]: https://github.com/solid/authentication-panel/issues/1
>   [2]: https://solidproject.org/
>   [3]: https://github.com/zenomt/webid-auth-protocol
>   [4]: https://github.com/zenomt/webid-auth-nginx
>   [5]: https://github.com/solid/webid-oidc-spec/issues/25
>
>
-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

--0000000000006dd0ca05a66bab02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Michael,

The proposal =
looks very promising.There is a need for a framework with an even higher ab=
straction. Decentralized issuance of bearer token is gaining=C2=A0space, as=
 in the open banking ecosystem we witness Clients which have to deal with m=
any AS or "Mechanism Endpoint" like you call it in the proposal.<=
/div>

In some situations, the "Mechanism Endpoint&q=
uot; can be=C2=A0 a device in the possession of the resource owner (RO) and=
 it initiates the original service request to the Client=C2=A0and it is not=
 open to receive a POST request. In which case the "POST token request=
" in Figure 1 will be replaced by a 401 response to the "Mechanis=
m Endpoint" that will in turn produce the bearer token and resent it t=
o the Client.

/Francis





hi WG.



i'd like to bring to your attention my OAuth-adjacent draft, draft-thor=
nburgh-fwk-dc-token-iss, for examination, comment, and maybe even considera=
tion:



- title: A Framework For Decentralized Bearer Token Issuance in HTTP

- datatracker: https://datatracke=
r.ietf.org/doc/draft-thornburgh-fwk-dc-token-iss/

- fancy-html: https://www.ietf.org/=
id/draft-thornburgh-fwk-dc-token-iss-00.html



TL;DR:

------

* bearer tokens are (still) appropriate, and even beneficial, for many use =
cases.



* OAuth has gaps (see for example TxAuth, draft-ietf-oauth-distributed), es=
pecially for the motivating case of decentralized identity systems and dece=
ntralized, independent RSes.



* this draft proposes a general form to support the motivating use case, bu=
t is applicable in other cases as well (including some of DPoP's).



the introduction section of the draft elaborates on the motivation and envi=
sioned use cases.



longer intro:

-------------

my proposal was initially motivated by semantic and security problems i saw=
 [1] in the Solid Project's [2] existing authentication system. that sy=
stem is based on WebID, OIDC, and proof-of-possession. it addresses the dec=
entralized identity problem (WebID + OIDC) and the decentralized, multiple,=
 independent RS problem, where neither the client nor the user's OpenID=
 Provider has prior knowledge of what RSes will be visited, and where the R=
S's authorization infrastructure is not (necessarily) the user's Op=
enID Provider. the system is especially intended to enable authenticated ac=
cess without requiring the user to log in separately to each RS. other than=
 its problems [1] it's pretty cool.



my solution to the problems with Solid's existing system is (essentiall=
y) for the client to be able to discover where and how to get a bearer toke=
n from a competent AS for a new RS it's visiting. initial versions (pre=
-I-D) [5][3] were very WebID-specific, but while developing it a more gener=
al solution emerged. reading through past messages in this WG, i think my a=
pproach may be of interest to some here. there is a superficial similarity =
to Jpop (in that there is a nonce in the WWW-Authenticate), but it is other=
wise substantially different.



of particular note, at least one (but definitely not all) use cases for DPo=
P can also be addressed by this proposal. in particular, a client can prove=
 current possession of a POP key to obtain a reusable bearer token constrai=
ned to one origin+realm, for an independent and arbitrarily short lifetime.=




i have an example/POC implementation of the "token_pop_endpoint" =
mechanism specifically for WebID and the Solid use case, in the form of an =
nginx ngx_auth_request_module, at [4].



full disclosure: at present the Solid Authentication Panel is leaning towar=
d an approach that uses substantially the same semantics as their current s=
ystem, but adapted to the syntax of DPoP. i am not in favor of this approac=
h, but i am in the minority.



this is long. thanks if you read this far.



-michael thornburgh





=C2=A0 [1]: https://github.com/solid/authentic=
ation-panel/issues/1

=C2=A0 [2]: https://solidproject.org/

=C2=A0 [3]: https://github.com/zenomt/webid-auth-prot=
ocol

=C2=A0 [4]: https://github.com/zenomt/webid-auth-nginx=


=C2=A0 [5]: https://github.com/solid/webid-oidc-sp=
ec/issues/25




-- 
=

Francis Pouatcha
Co-Founder and Techni=
cal Lead at adorys


--0000000000006dd0ca05a66bab02--


From nobody Mon May 25 23:03:31 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E3E3A0B26 for ; Mon, 25 May 2020 23:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86-vz96qHrqE for ; Mon, 25 May 2020 23:03:21 -0700 (PDT)
Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (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 2EAC23A0B24 for ; Mon, 25 May 2020 23:03:19 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id dSgGj74CM0xLkdSgHjgSGo; Mon, 25 May 2020 23:03:18 -0700
X-CMAE-Analysis: v=2.3 cv=D7M51cZj c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=48vgC7mUAAAA:8 a=xdqwTLYnAAAA:8 a=-u-YU2za4N9UWmFB5zEA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=JkxfWD9QpNFVG-6c:21 a=-68rJ_tc1RoGImx6:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=pGLkceISAAAA:8 a=0lhL6yGjzcYyPZIURakA:9 a=EVILO4TRa6uCCJAI:21 a=Ec08Onk6jMp4x0RA:21 a=9OfL4BNMrbms6Q34:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=I3GVSKNlf5WA1x-hengb:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References:  
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2id.com>
Date: Tue, 26 May 2020 09:03:16 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000308010705070301060701"
X-CMAE-Envelope: MS4wfETxXU+wONL5iS+3Wap6bSD4c42RvOPWafXekh7MqRCivaUmqOFvyjskeEZ8z1S0L/IbFIxI7JSArIbdVr9H7wTU6BxnnNHxbT2Uf4i2yu/SoVXYkOkG gZsGkjPE610esALbZBT+8NnsOXqTEj/wA67L3VaunQdi5xAIv25q7Kr+
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 06:03:27 -0000

This is a cryptographically signed message in MIME format.

--------------ms000308010705070301060701
Content-Type: multipart/alternative;
 boundary="------------07F764E670E63573430F64D7"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------07F764E670E63573430F64D7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

My understanding of the branding concept was to present different UIs to
resource owners during login and authorization, while keeping the OP /
AS the same, meaning identical issuer. In a spec it would be helpful to
spell out what branding means (and what not).

Regarding a token being issued for "personal" vs "business" and
confusion - the usage of the token is normally defined by its scope and
audience (RS) and if this rule is observed (and it's not relied solely
on the issuer URI for that) then clients shouldn't get confused here.

Vladimir

On 23/05/2020 06:26, Francis Pouatcha wrote:
> - I will go for Option 1 even if we have the same runtime instance
> producing tokens under different=C2=A0issuer uris.
> - Option 2 might expose security risk as many clients rely on
> the=C2=A0issuer to associate the=C2=A0 token with authorization context=
=2E By no
> way shall a token issued for "personal" be valid for "business".
> Therefore considering=C2=A0the=C2=A0use of the=C2=A0same issuer here mi=
ght lead to
> confusion at the=C2=A0RP.
> - In order to avoid confusion, AS must make=C2=A0sure each "brand"
> uses=C2=A0separated key material to produce the token.
>
> BTW:
> The term brand as used in the context of most Open Banking initiatives
> refers to entities consuming the Interface provided by TPPs (Third
> Party Providers).. TPPs play the roles of RPs in the oAuth2 context.
>
> Unless I misunderstood this thread we are using a brand here to refer
> to an AS virtual host (issuer-uri).
>
> Going forward, we need=C2=A0to=C2=A0agree on choosing another term to r=
efer to
> issuers, and leave the term "Brand" for consumers of TPP-interfaces.
>
> The core brand problem we will be facing in open banking is for having
> the AS display the "consumer-brand" logo to the RO in the consent scree=
n.
>
>
>     >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov
>     > wrote:
>     >>
>     >> With that said it makes sense to devise a structure which can
>     accommodate UI driven as well as automatic choice.
>     >>
>     >>=C2=A0 =C2=A0 =C2=A0 ? The UI driven chooser will need a human re=
adable
>     description and other UI hints. This can work for instance with
>     "classic" OIDC Discovery.
>     >>
>     >>=C2=A0 =C2=A0 =C2=A0 ? The "auto" chooser will need some sort of =
an ID. For a
>     bank chooser this means providing the issuer URI and an optional
>     brand ID and both must get registered together. Or, one could
>     define a standard brand ID (label) for banking operations and if
>     the "alternative_authorization_endpoints" is present look for it
>     in the structure, else fall back to the default
>     "authorization_endpoint".
>     >> Here is one possible layout which has IDs and UI hints:
>     >>
>     >> {
>     >>=C2=A0 =C2=A0...
>     >>=C2=A0 =C2=A0"alternative_authorization_endpoints": {
>     >>=C2=A0 =C2=A0 =C2=A0"banking": {
>     >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint":
>     >> "https://loadsamoney/business/auth"
>     >> ,
>     >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney business ba=
nking customers",
>     >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url":
>     >> "https://loadsamoney/business/logo.png"
>     >>
>     >>=C2=A0 =C2=A0 =C2=A0},
>     >>=C2=A0 =C2=A0 =C2=A0"personal": {
>     >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint":
>     >> "https://loadsamoney/consumer/auth"
>     >> ,
>     >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney personal cu=
stomers",
>     >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url":
>     >> "https://loadsamoney/consumer/logo.png"
>     >>
>     >>=C2=A0 =C2=A0 =C2=A0}
>     >>=C2=A0 =C2=A0}
>     >> }
>     >>
>     >>
>     >>
>     >> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>     >>> I think an id or label per endpoint set would be needed to
>     determine the set of endpoints to be used by a certain client.
>     >>>
>     >>> On the conceptual side, I?m asking myself how the complete
>     process is supposed to work. Who is deciding what issuer/endpoint
>     set combination to use. I assume in an open banking scenario,
>     there will always be some kind of bank chooser. Will this chooser
>     provide the client with issuer and brand id?
>     >>>
>     >>>
>     >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov
>     >
>     >>>>=C2=A0 wrote:
>     >>>>
>     >>>> A mapping like the one you propose can definitely work. Since
>     the user will be making the choice which endpoint to take with the
>     client app, having the logo_uri is a good idea. If the branded
>     endpoints differ somehow in policy one could also allow inclusion
>     of the op_policy_uri and op_tos_uri params from Discovery.
>     >>>>
>     >>>>
>     >>>>
>     https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDi=
scovery
>     >>>>
>     >>>>
>     >>>> Vladimir
>     >>>>
>     >>>> On 20/05/2020 19:16, Joseph Heenan wrote:
>     >>>>
>     >>>>> Thanks for your thoughts Vladimir!
>     >>>>>
>     >>>>> The client_id based solution I wasn?t previously aware of -
>     unfortunately it doesn?t solve the problem for app2app, as the
>     mobile OS selects the app to use based purely on the URL (and in
>     at least the iOS case will not offer the user a choice if multiple
>     apps claim to handle the same url).
>     >>>>>
>     >>>>> I think some kind of mapping like you suggest will work and
>     fallback, I wonder about a structure in the authorization server
>     metadata something like this:
>     >>>>>
>     >>>>> {
>     >>>>>=C2=A0 =C2=A0...
>     >>>>>=C2=A0 =C2=A0"alternative_authorization_endpoints": [
>     >>>>>=C2=A0 =C2=A0 =C2=A0{
>     >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint":
>     >>>>> "https://loadsamoney/business/auth"
>     >>>>> ,
>     >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney business=
 banking customers",
>     >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url":
>     >>>>> "https://loadsamoney/business/logo.png"
>     >>>>>
>     >>>>>=C2=A0 =C2=A0 =C2=A0},
>     >>>>>=C2=A0 =C2=A0 =C2=A0{
>     >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint":
>     >>>>> "https://loadsamoney/consumer/auth"
>     >>>>> ,
>     >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney personal=
 customers",
>     >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url":
>     >>>>> "https://loadsamoney/consumer/logo.png"
>     >>>>>
>     >>>>>=C2=A0 =C2=A0 =C2=A0}
>     >>>>>=C2=A0 =C2=A0]
>     >>>>> }
>     >>>>>
>     >>>>> And as you say, the existing authorization_endpoint can be a
>     fallback for clients that are unaware of the new spec or prefer
>     the simpler option of just using a single authorization endpoint.
>     Supporting the new spec would allow a better UX though so there?s
>     advantages to client to do so.
>     >>>>>
>     >>>>>> Speaking of mTLS, I'm not sure how the
>     "mtls_endpoint_aliases" can be sensibly combined with the proposed
>     multi-brand spec.
>     >>>>>>
>     >>>>>>
>     >>>>> I think that particular part is not really an issue as mtls
>     isn?t used at the authorization endpoint.
>     >>>>>
>     >>>>> Thanks
>     >>>>>
>     >>>>> Joseph
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov
>     >
>     >>>>>>=C2=A0 wrote:
>     >>>>>>
>     >>>>>> Hi Dave,
>     >>>>>>
>     >>>>>> In the absence of such a "multi-brand" spec we have tackled
>     this issue in the past by letting the "brand" be encoded in the
>     client_id. An alternative scenario is to do a "brand" lookup by
>     client_id. Then let the AS render the "branded" authZ endpoint.
>     >>>>>>
>     >>>>>> You're probably aware the mTLS spec is allowing for
>     endpoint aliases, so this is not the first time such as need has
>     occurred:
>     >>>>>>
>     >>>>>>
>     >>>>>> https://tools.ietf.org/html/rfc8705#section-5
>     >>>>>>
>     >>>>>>
>     >>>>>> One could devise a similar JSON object with mappings
>     "label" - "authorization_endpoint".
>     >>>>>>
>     >>>>>> Clients that are aware of the new spec will look it up,
>     those that are not will fall back to the std "authorization_endpoin=
t".
>     >>>>>>
>     >>>>>> Speaking of mTLS, I'm not sure how the
>     "mtls_endpoint_aliases" can be sensibly combined with the proposed
>     multi-brand spec.
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>> Vladimir
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
>     >>>>>>
>     >>>>>>> Dear OAuth WG
>     >>>>>>>
>     >>>>>>> We have an issue in the OpenID FAPI Working Group that we
>     believe affects the wider OAuth community.
>     >>>>>>>
>     >>>>>>> In summary: what is the recommended approach to discovery
>     (RFC8414) for Authorization Servers who support multiple "brands" .=

>     >>>>>>>
>     >>>>>>> If brands are completely separate, then it seems sensible
>     that each brand must have its own `issuer` and therefore its own
>     discovery document at the correct location (i.e. brand 1 would
>     have an issuer of
>     >>>>>>> "https://as/brand1" and a discovery document available at=C2=
=A0
>     https://as/.well-known/oauth-authorization-server/brand1
>     >>>>>>> ).
>     >>>>>>>
>     >>>>>>> However in the real world it is not always so simple. We
>     have many existing implementations in UK open banking that support
>     multiple authorization endpoints. Here is an example (thanks to
>     @Joseph Heenan )
>     >>>>>>>
>     >>>>>>>
>     >>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking,
>     one ?login page? for both business and personal customers.
>     >>>>>>>>
>     >>>>>>>> They have separate mobile apps for business/personal, and
>     are required to support app2app. This means they will definitely
>     be exposing multiple authorization endpoints (as there?s a 1:1
>     mapping of authorization endpoints to mobile apps) - the choice is
>     how they do this.
>     >>>>>>>>
>     >>>>>>>> Their choices are:
>     >>>>>>>>
>     >>>>>>>> 1. Multiple discovery endpoints (one for business, one
>     for personal), each with a different authorization endpoint,
>     multiple issuers (if their vendor allows this)
>     >>>>>>>> 2. Single discovery endpoint, single issuer, multiple
>     authorization endpoints listed in one discovery doc (one for
>     business, one for personal) some of which are hardcoded by the 3rd
>     party
>     >>>>>>>> 3. Multiple discovery endpoints each with a different
>     authorization endpoint, same issuer in all cases (breaks RFC8414
>     and OIDC Discovery)
>     >>>>>>>>
>     >>>>>>> Option 3 is invalid and that leaves us with options 1 and 2=
=2E
>     >>>>>>> Option 1 can be problematic as often it is in reality the
>     same `issuer` behind the scenes.
>     >>>>>>>
>     >>>>>>> We would like to get feedback on this issue and
>     potentially an extension to RFC8414 to allow the definition of
>     multiple authorization endpoints.
>     >>>>>>>
>     >>>>>>> Thanks in advance
>     >>>>>>>
>     >>>>>>> Dave Tonge
>     >>>>>>> Co-Chair FAPI WG
>     >>>>>>> Open ID Foundation
>     >>>>>>>
>     >>>>>>>
>     >>>>>>>
>     >>>> --
>     >>>> Vladimir Dzhuvinov
>
> --=20
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov


--------------07F764E670E63573430F64D7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
My understanding of the branding concept was to present different
      UIs to resource owners during login and authorization, while
      keeping the OP / AS the same, meaning identical issuer. In a spec
      it would be helpful to spell out what branding means (and what
      not).

    
Regarding a token being issued for "personal" vs "business" and
      confusion - the usage of the token is normally defined by its
      scope and audience (RS) and if this rule is observed (and it's not
      relied solely on the issuer URI for that) then clients shouldn't
      get confused here.

    
Vladimir

    

    
On 23/05/2020 06:26, Francis Pouatcha
      wrote:

    

    

      
      

        
- I will go for Option 1 even if we have the same runtime
          instance producing tokens under different=C2=A0issuer uris.
        
- Option 2 might expose security risk as many clients rely
          on the=C2=A0issuer to associate the=C2=A0 token with authorizat=
ion
          context. By no way shall a token issued for "personal" be
          valid for "business". Therefore considering=C2=A0the=C2=A0use o=
f
          the=C2=A0same issuer here might lead to confusion at the=C2=A0R=
P.

        
- In order to avoid confusion, AS must make=C2=A0sure each
          "brand" uses=C2=A0separated key material to produce the token.<=
br>
        

        


        

        
BTW:

        
The term brand as used in the context of most Open Banking
          initiatives refers to entities consuming the Interface
          provided by TPPs (Third Party Providers).. TPPs play the roles
          of RPs in the oAuth2 context.

        


        

        
Unless I misunderstood this thread we are using a brand
          here to refer to an AS virtual host (issuer-uri).

        


        

        
Going forward, we need=C2=A0to=C2=A0agree on choosing anothe=
r term to
          refer to issuers, and leave the term "Brand" for consumers of
          TPP-interfaces.

        


        

        
The core brand problem we will be facing in open banking is
          for having the AS display the "consumer-brand" logo to the RO
          in the consent screen.

        

          


            >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov <vladimir@connect2id.com>
            wrote:

            >> 

            >> With that said it makes sense to devise a structure
            which can accommodate UI driven as well as automatic choice.<=
br>
            >> 

            >>=C2=A0 =C2=A0 =C2=A0 ? The UI driven chooser will nee=
d a human
            readable description and other UI hints. This can work for
            instance with "classic" OIDC Discovery.

            >> 

            >>=C2=A0 =C2=A0 =C2=A0 ? The "auto" chooser will need s=
ome sort of an
            ID. For a bank chooser this means providing the issuer URI
            and an optional brand ID and both must get registered
            together. Or, one could define a standard brand ID (label)
            for banking operations and if the
            "alternative_authorization_endpoints" is present look for it
            in the structure, else fall back to the default
            "authorization_endpoint".

            >> Here is one possible layout which has IDs and UI
            hints:

            >> 

            >> {

            >>=C2=A0 =C2=A0...

            >>=C2=A0 =C2=A0"alternative_authorization_endpoints": {=


            >>=C2=A0 =C2=A0 =C2=A0"banking": {

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": =


            >> "https://loadsamoney/business/auth"

            >> ,

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney=
 business banking
            customers",

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 

            >> "https://loadsamoney/business/logo.png"

            >> 

            >>=C2=A0 =C2=A0 =C2=A0},

            >>=C2=A0 =C2=A0 =C2=A0"personal": {

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": =


            >> "https://loadsamoney/consumer/auth"

            >> ,

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney=
 personal
            customers",

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 

            >> "https://loadsamoney/consumer/logo.png"

            >> 

            >>=C2=A0 =C2=A0 =C2=A0}

            >>=C2=A0 =C2=A0}

            >> }

            >> 

            >> 

            >> 

            >> On 22/05/2020 09:59, Torsten Lodderstedt wrote:

            >>> I think an id or label per endpoint set would
            be needed to determine the set of endpoints to be used by a
            certain client.

            >>> 

            >>> On the conceptual side, I?m asking myself how
            the complete process is supposed to work. Who is deciding
            what issuer/endpoint set combination to use. I assume in an
            open banking scenario, there will always be some kind of
            bank chooser. Will this chooser provide the client with
            issuer and brand id? 

            >>> 

            >>> 

            >>>> On 22. May 2020, at 08:10, Vladimir
            Dzhuvinov <vladimir@connect=
2id.com>

            >>>>=C2=A0 wrote:

            >>>> 

            >>>> A mapping like the one you propose can
            definitely work. Since the user will be making the choice
            which endpoint to take with the client app, having the
            logo_uri is a good idea. If the branded endpoints differ
            somehow in policy one could also allow inclusion of the
            op_policy_uri and op_tos_uri params from Discovery.

            >>>> 

            >>>> 

            >>>> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDisco=
very

            >>>> 

            >>>> 

            >>>> Vladimir

            >>>> 

            >>>> On 20/05/2020 19:16, Joseph Heenan wrote:
            >>>> 

            >>>>> Thanks for your thoughts Vladimir!

            >>>>> 

            >>>>> The client_id based solution I wasn?t
            previously aware of - unfortunately it doesn?t solve the
            problem for app2app, as the mobile OS selects the app to use
            based purely on the URL (and in at least the iOS case will
            not offer the user a choice if multiple apps claim to handle
            the same url).

            >>>>> 

            >>>>> I think some kind of mapping like you
            suggest will work and fallback, I wonder about a structure
            in the authorization server metadata something like this:
=

            >>>>> 

            >>>>> {

            >>>>>=C2=A0 =C2=A0...

            >>>>>=C2=A0
            =C2=A0"alternative_authorization_endpoints": [

            >>>>>=C2=A0 =C2=A0 =C2=A0{

            >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization=
_endpoint": 

            >>>>> "https://loadsamo=
ney/business/auth"

            >>>>> ,

            >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description":=
 "loadsmoney
            business banking customers",

            >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 
            >>>>> "https://loadsamoney/business/logo.png"

            >>>>> 

            >>>>>=C2=A0 =C2=A0 =C2=A0},

            >>>>>=C2=A0 =C2=A0 =C2=A0{

            >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization=
_endpoint": 

            >>>>> "https://loadsamo=
ney/consumer/auth"

            >>>>> ,

            >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description":=
 "loadsmoney
            personal customers",

            >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": 
            >>>>> "https://loadsamoney/consumer/logo.png"

            >>>>> 

            >>>>>=C2=A0 =C2=A0 =C2=A0}

            >>>>>=C2=A0 =C2=A0]

            >>>>> }

            >>>>> 

            >>>>> And as you say, the existing
            authorization_endpoint can be a fallback for clients that
            are unaware of the new spec or prefer the simpler option of
            just using a single authorization endpoint. Supporting the
            new spec would allow a better UX though so there?s
            advantages to client to do so.

            >>>>> 

            >>>>>> Speaking of mTLS, I'm not sure how
            the "mtls_endpoint_aliases" can be sensibly combined with
            the proposed multi-brand spec.

            >>>>>> 

            >>>>>> 

            >>>>> I think that particular part is not
            really an issue as mtls isn?t used at the authorization
            endpoint.

            >>>>> 

            >>>>> Thanks

            >>>>> 

            >>>>> Joseph

            >>>>> 

            >>>>> 

            >>>>> 

            >>>>>> On 20 May 2020, at 16:07, Vladimir
            Dzhuvinov <vladimir@connect=
2id.com>

            >>>>>>=C2=A0 wrote:

            >>>>>> 

            >>>>>> Hi Dave,

            >>>>>> 

            >>>>>> In the absence of such a
            "multi-brand" spec we have tackled this issue in the past by
            letting the "brand" be encoded in the client_id. An
            alternative scenario is to do a "brand" lookup by client_id.
            Then let the AS render the "branded" authZ endpoint.

            >>>>>> 

            >>>>>> You're probably aware the mTLS spec
            is allowing for endpoint aliases, so this is not the first
            time such as need has occurred:

            >>>>>> 

            >>>>>> 

            >>>>>> https://tools.ietf.org/html/rfc8705#section-5

            >>>>>> 

            >>>>>> 

            >>>>>> One could devise a similar JSON
            object with mappings "label" - "authorization_endpoint".

            >>>>>> 

            >>>>>> Clients that are aware of the new
            spec will look it up, those that are not will fall back to
            the std "authorization_endpoint".

            >>>>>> 

            >>>>>> Speaking of mTLS, I'm not sure how
            the "mtls_endpoint_aliases" can be sensibly combined with
            the proposed multi-brand spec.

            >>>>>> 

            >>>>>> 

            >>>>>> 

            >>>>>> Vladimir

            >>>>>> 

            >>>>>> 

            >>>>>> 

            >>>>>> On 20/05/2020 15:07, Dave Tonge
            wrote:

            >>>>>> 

            >>>>>>> Dear OAuth WG

            >>>>>>> 

            >>>>>>> We have an issue in the OpenID
            FAPI Working Group that we believe affects the wider OAuth
            community.

            >>>>>>> 

            >>>>>>> In summary: what is the
            recommended approach to discovery (RFC8414) for
            Authorization Servers who support multiple "brands" .

            >>>>>>> 

            >>>>>>> If brands are completely
            separate, then it seems sensible that each brand must have
            its own `issuer` and therefore its own discovery document at
            the correct location (i.e. brand 1 would have an issuer of 
            >>>>>>> "https://as/brand1"
            and a discovery document available at=C2=A0 https://as/.well-known/oauth-authorization-server/brand1

            >>>>>>> ).

            >>>>>>> 

            >>>>>>> However in the real world it is
            not always so simple. We have many existing implementations
            in UK open banking that support multiple authorization
            endpoints. Here is an example (thanks to @Joseph Heenan )
=

            >>>>>>> 

            >>>>>>> 

            >>>>>>>> Bank ?loadsamoney? has one
            idp and, for internet banking, one ?login page? for both
            business and personal customers.

            >>>>>>>> 

            >>>>>>>> They have separate mobile
            apps for business/personal, and are required to support
            app2app. This means they will definitely be exposing
            multiple authorization endpoints (as there?s a 1:1 mapping
            of authorization endpoints to mobile apps) - the choice is
            how they do this.

            >>>>>>>> 

            >>>>>>>> Their choices are:

            >>>>>>>> 

            >>>>>>>> 1. Multiple discovery
            endpoints (one for business, one for personal), each with a
            different authorization endpoint, multiple issuers (if their
            vendor allows this)

            >>>>>>>> 2. Single discovery
            endpoint, single issuer, multiple authorization endpoints
            listed in one discovery doc (one for business, one for
            personal) some of which are hardcoded by the 3rd party

            >>>>>>>> 3. Multiple discovery
            endpoints each with a different authorization endpoint, same
            issuer in all cases (breaks RFC8414 and OIDC Discovery)

            >>>>>>>> 

            >>>>>>> Option 3 is invalid and that
            leaves us with options 1 and 2. 

            >>>>>>> Option 1 can be problematic as
            often it is in reality the same `issuer` behind the scenes.
            >>>>>>> 

            >>>>>>> We would like to get feedback
            on this issue and potentially an extension to RFC8414 to
            allow the definition of multiple authorization endpoints.
=

            >>>>>>> 

            >>>>>>> Thanks in advance

            >>>>>>> 

            >>>>>>> Dave Tonge

            >>>>>>> Co-Chair FAPI WG

            >>>>>>> Open ID Foundation

            >>>>>>> 

            >>>>>>> 

            >>>>>>> 

            >>>> -- 

            >>>> Vladimir Dzhuvinov

          

        

        -- 

        

          

            

              

                

                  

                    

                      

                        

                          
Francis Pouatcha

                          
Co-Founder and Technical Lead at adorys
                          
                        

                      

                    

                  

                

              

            

          

        

      

      

      

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


    

    
--=20
Vladimir Dzhuvinov

  


--------------07F764E670E63573430F64D7--

--------------ms000308010705070301060701
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
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjYwNjAzMTZaMC8G
CSqGSIb3DQEJBDEiBCAGKIqQxTMePpjkfqk7kGkq3WIrg1EPuvhYKmAUPD4iszBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAGbFjdsBxmu90I2ZHnNlRe5/XJg2EbuSDUSvXTPj/wG1Oxpj
YwiMkmlDw59U670+2yHDKBiMTL3PV3RzNzkwtPCrdpzmc/CV4Vldvwk27i+ZoW3IxR4o96Qw
GdSSUBfGQ0J3HbQ2RHrEJKYyZBb/nVwEBipccD8teRyUh93WWHCbrSWywRm6W9SwdHhpTjKh
jCeoOKwdmjuPClicWxQTWxDP7JUmzzGv7Egydn1+8NWJo8rRSi21qrUrntF8w7WR28JzG2l9
FfMuj3pBoLAb/eSG9II8IhyitE7mtBCaPxtKRVrkaBhudSvoz0JbKB6PxCwzhekGN2bmkRhT
KkcoGAoAAAAAAAA=
--------------ms000308010705070301060701--


From nobody Tue May 26 05:51:44 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7D3A0A07 for ; Tue, 26 May 2020 05:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1nWnXlf1Sli for ; Tue, 26 May 2020 05:51:39 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE4E3A0F19 for ; Tue, 26 May 2020 05:51:36 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 33DD1F4071A; Tue, 26 May 2020 05:51:26 -0700 (PDT)
To: mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: resnick@episteme.net, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200526125126.33DD1F4071A@rfc-editor.org>
Date: Tue, 26 May 2020 05:51:26 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 12:51:43 -0000

The following errata report has been submitted for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--------------------------------------
Type: Editorial
Reported by: Pete Resnick 

Section: 7.1

Original Text
-------------
   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7157, May 2015,
              .


Corrected Text
--------------
   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              .


Notes
-----
DOI has a typo: 7157 instead of 7517.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--------------------------------------
Title               : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
Publication Date    : April 2016
Author(s)           : M. Jones, J. Bradley, H. Tschofenig
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Tue May 26 14:44:32 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47B3A095F for ; Tue, 26 May 2020 14:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOyyzRCMDsRA for ; Tue, 26 May 2020 14:44:26 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52403A0936 for ; Tue, 26 May 2020 14:44:25 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id x27so13206777lfg.9 for ; Tue, 26 May 2020 14:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nZOiSzJBg6NxS6yjjPa1mJfIvxmpIlTGx8BkoXm6T9E=; b=GJOhsMWCpw33rEWlfAmWvkMXGuML7erJlAHR7KVsRBgmuyk4/MC14TkxTpMRl3i6OQ yYoJf5aS0tkNr5z/euHDBoaWvfFeg7wb2PGGlCXbOXxZd7j08Etag7fI39SvQgliwKgE LXZ0RcePjKRRmmhQEuo+BU9b+g30+f29Lt/Jvb0eOgHF7oNk3YLc2//3okKbGQPw/ruB DEhN+yfiRlt6Zl/mWppL2wjGBT/1TE6zugHEpJ6H/0Bbcv3DH2/NDDGX7pOHljVg7KGz 36OhV5tvqvir7wIu5VuUN+qJgr/PShYi7mUIG84In4d7zBjcIgkRrB387FwhYBSBpV5n 5ZNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nZOiSzJBg6NxS6yjjPa1mJfIvxmpIlTGx8BkoXm6T9E=; b=eV7egrYmAfzTNkjg+9R16LLcsOQLHpIhtGt3g7W2nqucG4399HsuoxKDJqyG83M+ow LW1Dx4HdvGLyqh/NnTKIiQcrzBKGgB+RbOLd4mUCivtPs7lXnOx6s6qeZYzO3v9QqBgY DGv6P9Am4ejx7wMZTaHjbopLNVz0+hFoLkQvK65uDbGeAv8fk/DEnSOAtPXtz42eVVxs HKwvjYSKlVAXTeQ+vhqG9oqr41IisaILyEyczN1VcUZ46ju5Yj+794VASUPQWUYf9QZI ty5qWkmIJziqR6vB3bciVXWTrbLGg5Nei9O/M3t331SOsTD+cEB40vFfoQRWbhIuPzD5 KmDQ==
X-Gm-Message-State: AOAM532FAtY8iUlWvUkNrty6GyjVR9CdaIAyouQ5wKM09JoQrSv6iFu9 jp0+caACHfwbEOxpoC6b5FWBrug96V3YfGxog9o=
X-Google-Smtp-Source: ABdhPJzgYq6UhjbaonP1XTC5+rY9KQC88MOXLE0tCV+MuqmoQnP80neCHN1bgg+Rq0PXP4kiwgLZ7XB1lqniUEVBc9w=
X-Received: by 2002:ac2:4c95:: with SMTP id d21mr1443557lfl.22.1590529462828;  Tue, 26 May 2020 14:44:22 -0700 (PDT)
MIME-Version: 1.0
References:  <67F643A9-47E5-4339-B6B0-E39C7B959EF7@gmail.com>  
In-Reply-To: 
From: Dick Hardt 
Date: Tue, 26 May 2020 14:43:56 -0700
Message-ID: 
To: Mike Jones 
Cc: Aaron Parecki , Nov Matake ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a30a3c05a693fff9"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 21:44:31 -0000

--000000000000a30a3c05a693fff9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mike

I'm not sure what you are suggesting as it is not clear if you are
describing the client or the server. It also seems like you are suggesting
we create a new signal for requiring PKCE. Would that be optional in OAuth
2.1, or is it required? What would happen to existing clients?

/Dick

On Wed, May 20, 2020 at 4:14 PM Mike Jones  wrote:

> I disagree with the language below.  It=E2=80=99s perfectly legal to swit=
ch, as
> the same client may do both OpenID Connect and pure OAuth interactions,
> depending upon whether the =E2=80=9Copenid=E2=80=9D scope is included.  B=
oth can be secure.
>
>
>
> If the OpenID Connect `nonce` is used to mitigate authorization code
> injection instead of `code_challenge`, client and authorization server
> MUST ensure that the mitigation is applied to every interaction with
> the client and that the client cannot switch between `code_challenge`
> and `nonce`. For example, the presence of a `nonce` parameter in the
> authorization request is not sufficient to determine that the
> `code_verifier` check can be skipped.
>
>
>
> I=E2=80=99d rather that the onus be put on new code, than existing code. =
 For
> instance new code wanting to require PKCE on all interactions could use
> something like a =E2=80=9Crequire_pkce=E2=80=9D dynamic client registrati=
on parameter (or
> corresponding static registration).  Otherwise, it should be up to the
> client which of the mechanisms to use.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Wednesday, May 20, 2020 3:48 PM
> *To:* Nov Matake 
> *Cc:* Mike Jones ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] proposed resolution for PKCE in
> OAuth 2.1
>
>
>
> So if I'm understanding this correctly, it sounds like the AS needs to
> reject a token request with code_verifier if the authorization code was
> issued in response to a request that did not contain a code_challenge. Th=
is
> to me sounds like it would be simpler to just say the code_challenge and
> code_verifier are always required.
>
>
>
> That said, I do understand the previously discussed concerns around
> existing OpenID Connect clients.
>
>
>
> I believe the text that Daniel proposed is the best of both worlds, and I
> support making this change in both OAuth 2.1 and the Security BCP.
>
>
>
> Aaron Parecki
>
>
>
>
>
>
>
> On Tue, May 19, 2020 at 9:29 AM Nov Matake  wrote:
>
> Yes.
>
>
>
> The root problem isn=E2=80=99t the mix-use of PKCE and nonce, it=E2=80=99=
s PKCE
> implementation bug.
>
> Yeah, all PKCE implementation MUST reject such requests, regardless it=E2=
=80=99s
> OAuth 2.1 or 2.0.
>
>
>
> (and it=E2=80=99s probably because of PKCE spec=E2=80=99s ambiguity..)
>
>
>
> 2020/05/20 1:13=E3=80=81Mike Jones =E3=81=AE=
=E3=83=A1=E3=83=BC=E3=83=AB:
>
>
>
> So it sounds me like the fix is to have servers reject PKCE requests with
> incomplete parameter sets: requests that only contains one of
> code_challenge and code_verified.  Will that eliminate the attack, Nov?
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Nov Matake
> *Sent:* Monday, May 18, 2020 11:50 PM
> *To:* Daniel Fett 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
>
>
> Sure, feel free to add the senario to your post.
>
>
>
> FYI:
>
> my OAuth2 server ruby gem rejects such token requests,
>
>
> https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/ext=
ension/pkce.rb#L28
>
> and Google also does the same.
>
> https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046
>
>
>
> So I'm guessing such behavior is relatively rare-case, hopefully.
>
>
>
> iPad=E3=81=8B=E3=82=89=E9=80=81=E4=BF=A1
>
>
>
> 2020/05/19 15:43=E3=80=81Daniel Fett =E3=81=AE=E3=83=
=A1=E3=83=BC=E3=83=AB:
>
> =EF=BB=BF
>
> Hi,
>
>
>
> Am 19.05.20 um 04:55 schrieb Nov Matake:
>
> I thought the server MUST reject such token requests, but I couldn=E2=80=
=99t find
> such definition in RFC7636...
>
>
>
> > The client will send the code, along with a (now not matching)
> code_verifier to the server. The server will ignore the code_verifier (as
> it was not expected) and send back an access token and ID token to the
> client.
>
>
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepk=
ce-sidestep-attack
>
>
>
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2=
=80=9D
> would be possible.
>
> I *think* that there is nothing preventing servers from sometimes using
> PKCE and sometimes using Nonce. I assume that this is out of the scope of
> the existing specifications.
>
> I would be interested to hear how actual implementations handle this in
> practice.
>
>
>
> Plus, with such AS behavior, CSRF protection using PKCE can also be
> bypassed as below.
>
> 1. The attacker removes code_challenge from his/her own AuthZ
> Req, receives a non-code_challenge-bound code, and sends it to the victim=
.
>
> 2. The client receives the attacker=E2=80=99s code from the victim, and s=
ends it
> to the AS w/ the valid code_verifier bound to the victim=E2=80=99s browse=
r session.
>
> 3. The AS ignores the code_verifier and returns tokens.
>
>
>
> If that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can be =
weaker
> than expected..
>
> Excellent point!
>
> Would it be okay if I add that attack to the original post (with credits,
> of course)?
>
> -Daniel
>
>
>
> nov
>
>
>
> 2020/05/19 1:54=E3=80=81Daniel Fett =E3=81=AE=E3=83=
=A1=E3=83=BC=E3=83=AB:
>
>
>
> Hi all,
>
>
>
> Talking to Torsten, we realized that providing a generic extension point
> here is probably not a good idea. It is really hard to tell what protects
> you from code injection and what does not, and people might come up with
> all sorts of non-standard and potentially insecure solutions.
>
>
>
> Even just for PKCE vs. Nonce, it is not obvious if they provide the same
> level of protection. In an attempt to answer this question, I tried to co=
me
> up with a more systematic analysis of "PKCE vs Nonce". I wrote up my
> results here:
>
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>
>
> Although this is not a formal analysis, I hope that I have covered all
> interesting cases. Please review the text and let me know if I have misse=
d
> something or if there are any mistakes.
>
> The main results are:
>
>    1. In terms of protection against CSRF and code misuse, PKCE and Nonce
>    provide similar levels of security, with a slight advantage for PKCE.
>    2. In practice, a circumvention of both mechanisms, however, is
>    possible if an AS allows a client to choose between PKCE and Nonce and=
 the
>    client makes use of this freedom. I propose to call this attack the
>    Nonce/PKCE Sidestep Attack. =E2=86=92 Please review the attack descrip=
tion in the
>    analysis.
>    3. To avoid the Nonce/PKCE Sidestep Attack, clients must not switch
>    between using only PKCE and only Nonce (but may use both in parallel, =
or
>    switch between using only PKCE and PKCE+Nonce). Authorization servers =
must
>    enforce PKCE unless they know that the client uses Nonce for all of it=
s
>    flows (and checks the Nonce value). The presence of a nonce parameter =
in
>    the authorization request is not sufficient to determine if a client
>    actually checks the nonce claim in the ID token.
>
> As you can see, already having two more-or-less well-understood mechanism=
s
> is hard enough to wrap your head around from a security standpoint. We
> should therefore make PKCE the default and Nonce an option for backwards
> compatibility.
>
> To this end, I would like to propose the follwing strawman, based on
> Torsten's and Aaron's suggestions:
>
> An AS MUST reject requests without a code_challenge from public
> clients, and MUST reject such requests from other clients unless there
> is reasonable assurance that the client mitigates authorization code
> injection using the OpenID Connect Nonce mechanism and that this
> mitigation is used for all interactions with the client. See section
> 9.7 for details.
>
> Section 9.7:
>
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. The use of the
> `code_challenge` parameter is RECOMMENDED to this end. For
> confidential clients, the OpenID Connect `nonce` parameter and ID
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
> `code_challenge` parameter for this purpose. The `code_challenge` or
> OpenID Connect `nonce` value MUST be transaction-specific and securely
> bound to the client and the user agent in which the transaction was
> started.
>
> If the OpenID Connect `nonce` is used to mitigate authorization code
> injection instead of `code_challenge`, client and authorization server
> MUST ensure that the mitigation is applied to every interaction with
> the client and that the client cannot switch between `code_challenge`
> and `nonce`. For example, the presence of a `nonce` parameter in the
> authorization request is not sufficient to determine that the
> `code_verifier` check can be skipped.
>
>
>
> Of course, we need to adapt the wording in the Security BCP accordingly.
>
> -Daniel
>
>
>
>
>
> Am 15.05.20 um 01:01 schrieb Mike Jones:
>
> I agree with Nov that obscuring the language in 9.7 would be a disservice=
 to developers.
>
>
>
> The Security BCP, which has already going the WGLC, explicitly calls out =
the use of nonce as part of the best practices.  OAuth 2.1 should do no les=
s.
>
>
>
> The 9.7 language that Aaron proposed was the result of many people's cont=
ributions and a vigorous discussion.  Let's publish the next version of 2.1=
 with that language intact, as I believe it represents at least a local poi=
nt of hard-won consensus.  Let's get that language into the record of draft=
s.
>
>
>
> There's always time to debate it and change it later in subsequent drafts=
, but let's not now lose what it took a lot of effort to achieve.
>
>
>
>     Thanks,
>
>     -- Mike
>
>
>
> -----Original Message-----
>
> From: Nov Matake  
>
> Sent: Thursday, May 14, 2020 3:18 AM
>
> To: Torsten Lodderstedt  
>
> Cc: OAuth WG  ; Mike Jones  
>
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
>
>
> There is no specific mechanism right now.
>
> But future developers won=E2=80=99t be able to read the reason why the ex=
tension point is given only for confidential clients.
>
>
>
> On May 14, 2020, at 18:32, Torsten Lodderstedt  =
 wrote:
>
>
>
> Are you aware of any suitable mechanism? I=E2=80=99m asking since from my=
 perspective this clause is mainly intended to allow existing OpenID Connec=
t deployments to use nonce instead of PKCE in combination with OAuth 2.1. I=
t=E2=80=99s a compromise. I think we should not encourage others to invent =
their own OAuth security mechanisms.
>
>
>
> On 14. May 2020, at 09:37, Nov Matake   wrote:
>
>
>
> Hi,
>
>
>
> Why not allowing public clients use "other suitable mechanisms=E2=80=9D t=
hen?
>
> OAuth WG can allow both type of clients do so, then OIDF will define nonc=
e as the alternative only for confidential clients.
>
>
>
> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt  =E3=81=AE=E3=
=83=A1=E3=83=BC=E3=83=AB:
>
>
>
> Hi all,
>
>
>
> I would also like to thank everybody for the substantial discussion.
>
>
>
> The proposed change for Section 4.1.2.1 works for me (as already stated).=
 I=E2=80=99m not fully comfortable with the proposed change for Section 9.7=
 for the following reasons:
>
>
>
> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE=
 instead of requiring it (with a well-defined exception).
>
> - Given the latest findings re nonce I don=E2=80=99t feel comfortable wit=
h recommending any mechanism that this WG is not responsible for and thus d=
id not conduct the security threat analysis for. I think the better way for=
 us as WG is to define the extension point for other mechanisms. The OpenID=
 Foundation (or any other body) can then fill in and issue a statement that=
 nonce (or another suitable mechanism) fulfils the requirements of the exte=
nsion point.
>
>
>
> Based on this considerations, I propose the following text for Section 9.=
7:
>
>
>
> Clients MUST prevent injection (replay) of authorization codes into
>
> the authorization response by attackers. Public clients MUST use the
>
> "code_challenge=E2=80=9D with a transaction-specific value that is secure=
ly
>
> bound to the client and the user agent in which the transaction was
>
> started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=
=9D in the
>
> same way or other suitable mechanisms to mitigate authorization code
>
> injection.
>
>
>
> This text follows the logic in Section 4.1.2.1 and allows use of the nonc=
e for confidential clients.
>
>
>
> best regards,
>
> Torsten.
>
>
>
> On 12. May 2020, at 02:21, Mike Jones   wrote:
>
>
>
> That works for me.  Thanks all for the useful back-and-forth that got us =
to this point of clarity.  I suspect many of us learned things along the wa=
y; I know that I did!
>
>
>
>                                                     Cheers,
>
>                                                     -- Mike
>
>
>
> From: Aaron Parecki  
>
> Sent: Monday, May 11, 2020 4:55 PM
>
> To: OAuth WG  
>
> Cc: Neil Madden  ; =
Mike Jones
>
>  
>
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
>
>
> Thank you Neil.
>
>
>
> To address Mike's concerns in the previous threads, I would like to also =
update section 9.7 with the following text:
>
>
>
> Clients MUST prevent injection (replay) of authorization codes into
>
> the authorization response by attackers. The use of the
>
> `code_challenge` parameter is RECOMMENDED to this end. For
>
> confidential clients, the OpenID Connect `nonce` parameter and ID
>
> Token Claim {{OpenID}} MAY be used instead of or in addition to the
>
> `code_challenge` parameter for this purpose. The `code_challenge`
>
> or OpenID Connect `nonce` value MUST be transaction-specific and
>
> securely bound to the client and the user agent in which the transaction =
was started.
>
>
>
> This change better clarifies the specific circumstances under which the "=
nonce" parameter is sufficient to protect against authorization code inject=
ion.
>
>
>
> Aaron Parecki
>
>
>
> On Mon, May 11, 2020 at 11:55 AM Neil Madden  =
 wrote:
>
> I am happy with this proposed wording. Thanks for updating it.
>
>
>
> =E2=80=94 Neil
>
>
>
>
>
> On 11 May 2020, at 19:52, Aaron Parecki   wrote:
>
>
>
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
>
>
>
> We would like to propose the following text, which is a slight variation =
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (h=
ttps://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) tha=
t begins with "If the client does not send the "code_challenge" in the requ=
est..."
>
>
>
> "An AS MUST reject requests without a code_challenge from public clients,=
 and MUST reject such requests from other clients unless there is reasonabl=
e assurance that the client mitigates authorization code injection in other=
 ways.. See section 9.7 for details."
>
>
>
> Section 9.7 is where the nuances of PKCE vs nonce are described.
>
>
>
> As Neil described, we believe this will allow ASs to support both OAuth 2=
.0 and 2.1 clients simultaneously. The change from Neil's text is the clari=
fication of which threats, and changing to MUST instead of SHOULD. The "MUS=
T...unless" is more specific than "SHOULD", and since we are already descri=
bing the explicit exception to the rule, it's more clear as a MUST here.
>
>
>
> Aaron Parecki
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
=E1=90=A7

--000000000000a30a3c05a693fff9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Mike

I'm not su=
re what you are suggesting as it is not clear if you are describing the cli=
ent or the server. It also seems like you are suggesting we create a new si=
gnal for requiring PKCE. Would that be optional in OAuth 2.1, or is it requ=
ired? What would happen to existing clients?

/Dick=


On Wed, May 20, 2020 at 4:14 PM Mike Jones <Michael.Jon=
es=3D40microsoft.com@dmar=
c.ietf.org> wrote:











I disagree with t=
he language below.=C2=A0 It=E2=80=99s perfectly legal to switch, as the sam=
e client may do both OpenID Connect and pure OAuth interactions, depending =
upon whether the =E2=80=9Copenid=E2=80=9D scope is included.=C2=A0 Both can
 be secure.


=C2=A0<=
/u>


If the OpenID Connect `nonce` is used to mitigate authorization =
code

injection instead of `code_challenge`, client and authorization server<=
/tt>

MUST ensure that the mitigation is applied to every interaction with

the client and that the client cannot switch between `code_challenge`

and `nonce`. For example, the presence of a `nonce` parameter in the

authorization request is not sufficient to determine that the

`code_verifier` check can be skipped.


=C2=A0<=
/u>


I=E2=80=99d rathe=
r that the onus be put on new code, than existing code.=C2=A0 For instance =
new code wanting to require PKCE on all interactions could use something li=
ke a =E2=80=9Crequire_pkce=E2=80=9D dynamic client registration parameter
 (or corresponding static registration).=C2=A0 Otherwise, it should be up t=
o the client which of the mechanisms to use.


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>




From: Aaron Parecki <aaron@parecki.com> 

Sent: Wednesday, May 20, 2020 3:48 PM

To: Nov Matake <matake@gmail.com>

Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] proposed resolution for PKCE in O=
Auth 2.1




=C2=A0




So if I'm understanding this correctly, it sound=
s like the AS needs to reject a token request with code_verifier if the aut=
horization code was issued in response to a request that did not contain a =
code_challenge. This to me sounds like
 it would be simpler to just say the code_challenge and code_verifier are a=
lways required.




=C2=A0






That said, I do understand the previously discussed =
concerns around existing OpenID Connect clients.






=C2=A0






I believe the text that Daniel proposed is the best =
of both worlds, and I support making this change in both OAuth 2.1 and the =
Security BCP.






=C2=A0






Aaron Parecki




=C2=A0




=C2=A0










=C2=A0






On Tue, May 19, 2020 at 9:29 AM Nov Matake <matake@gmail.com> w=
rote:








Yes.




=C2=A0




The root problem isn=E2=80=99t the mix-use of PKCE a=
nd nonce, it=E2=80=99s PKCE implementation bug.






Yeah, all PKCE implement=
ation MUST reject such requests, regardless it=E2=80=99s OAuth 2.1 or 2.0.<=
/span>






=C2=A0






(and it=E2=80=99s=C2=A0p=
robably=C2=A0because of PKCE spec=E2=80=
=99s ambiguity..)



















2020/05/20 1:13=E3=80=81Mike Jones <Michael.Jones@microsoft.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3=
=83=AB:




=C2=A0








So it sounds me l=
ike the fix is to have servers reject PKCE requests with incomplete paramet=
er sets: requests that only contains one of code_challenge and code_verifie=
d.=C2=A0 Will that eliminate the attack, Nov?






=C2=A0<=
/u>






=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>










From:=C2=A0OAuth <oauth-bounces@ietf.org>=C2=A0=
On Behalf Of=C2=A0Nov Matake

Sent:=C2=A0Monday, May 18, 2020 11:50 PM

To:=C2=A0Daniel Fett <fett@danielfett.de>

Cc:=C2=A0oauth@i=
etf.org

Subject:=C2=A0Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2=
.1










=C2=A0








Sure, feel free to add the senario to your post.<=
/u>










=C2=A0








FYI:






my OAuth2 server ruby gem rejects such token request=
s,









and Google also does the same.











=C2=A0










So I'm guessing such behavior is relatively rare=
-case, hopefully.








=C2=A0








iPad=C2=A0





2020/05/19 15:43=E3=80=81Daniel Fett <=
fett@danielfett.de<=
/a>>=E3=81=AE=E3=83=A1=
=E3=83=BC=E3=83=AB:








=EF=BB=BF=C2=A0








Hi,










=C2=A0










Am 19.05.20 um 04:55 schrieb Nov Matake:










I thought the server MUST reject such token requests=
, but I couldn=E2=80=99t find such definition in RFC7636...






I *think*=
 that there is nothing preventing servers from sometimes using PKCE and som=
etimes using Nonce. I assume that this is out of the scope of the existing =
specifications.


I would b=
e interested to hear how actual implementations handle this in practice.=













=C2=A0










Plus, with such AS behavior, CSRF protection using P=
KCE can also be bypassed as below.










1. The attacker removes code_challenge from his/her =
own AuthZ Req,=C2=A0receives=C2=A0a non-code_challenge-bound code, and send=
s it to the victim.










2. The client receives the attacker=E2=80=99s code f=
rom the victim, and sends it to the AS w/ the valid code_verifier bound to =
the victim=E2=80=99s browser session.










3. The AS ignores the code_verifier and returns toke=
ns.










=C2=A0










If that=E2=80=99s the case, current OAuth 2.0 PKCE i=
mplementation can be weaker than expected..












Excellent=
 point!


Would it =
be okay if I add that attack to the original post (with credits, of course)=
?


-Daniel












=C2=A0










nov












=C2=A0









2020/05/19 1:54=E3=80=81Daniel Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:<=
/u>








=C2=A0












Hi all,










=C2=A0










Talking to Torsten, we realized that providing a gen=
eric extension point here is probably not a good idea. It is really hard to=
 tell what protects you from code injection and what does not, and people m=
ight come up with all sorts of non-standard
 and potentially insecure solutions.=C2=A0










=C2=A0










Even just for PKCE vs. Nonce, it is not obvious if t=
hey provide the same level of protection. In an attempt to answer this ques=
tion, I tried to come up with a more systematic analysis of "PKCE vs N=
once". I wrote up my results here:











Although this is not a formal analysis, I hope that I have covered all inte=
resting cases. Please review the text and let me know if I have missed some=
thing or if there are any mistakes.



The main results are:




    

  1. In terms of protection against CSRF and code misuse=
, PKCE and Nonce provide similar levels of security, with a slight advantag=
e for PKCE.
  2. In practice, a circum=
vention of both mechanisms, however, is possible if an AS allows a client t=
o choose between PKCE and Nonce and the client makes use of this freedom. I=
 propose to call this attack the
 Nonce/PKCE Sidestep Attack. =E2=86=92 Please review the attack description=
 in the analysis.
  3. To avoid the No=
nce/PKCE Sidestep Attack, clients must not switch between using only PKCE a=
nd only Nonce (but may use both in parallel, or switch between using only P=
KCE and PKCE+Nonce). Authorization servers
 must enforce PKCE unless they know that the client uses Nonce for all of i=
ts flows (and checks the Nonce value). The presence of a nonce parameter in=
 the authorization request is not sufficient to determine if a client actua=
lly checks the nonce claim in the
 ID token.




As you can see, already having two more-or-less well=
-understood mechanisms is hard enough to wrap your head around from a secur=
ity standpoint. We should therefore make PKCE the default and Nonce an opti=
on for backwards compatibility.






To this end, I would like to propose the follwing st=
rawman, based on Torsten's and Aaron's suggestions:





An AS MUST reject=
 requests without a code_challenge from public

clients, and MUST reject such requests from other clients unless there<=
/tt>

is reasonable assurance that the client mitigates authorization code

injection using the OpenID Connect Nonce mechanism and that this
mitigation is used for all interactions with the client. See section

9.7 for details.



Section 9.7:



Clients MUST prevent injection (replay) =
of authorization codes into

the authorization response by attackers. The use of the

`code_challenge` parameter is RECOMMENDED to this end. For

confidential clients, the OpenID Connect `nonce` parameter and ID<=
br>
Token Claim {{OpenID}} MAY be used instead of or in addition to the

`code_challenge` parameter for this purpose. The `code_challenge` or

OpenID Connect `nonce` value MUST be transaction-specific and securely<=
/tt>

bound to the client and the user agent in which the transaction was

started.



If the OpenID Connect `nonce` is used to mitigate authorization code

injection instead of `code_challenge`, client and authorization server<=
/tt>

MUST ensure that the mitigation is applied to every interaction with

the client and that the client cannot switch between `code_challenge`

and `nonce`. For example, the presence of a `nonce` parameter in the

authorization request is not sufficient to determine that the

`code_verifier` check can be skipped.






=C2=A0






Of course, we need to adapt the wording in the Secur=
ity BCP accordingly.






-Daniel






=C2=A0








=C2=A0










Am 15.05.20 um 01:01 schrieb Mike Jones:








I agree with Nov that obscuring the language in 9.7 would be a disserv=
ice to developers.


=C2=A0


The Security BCP, which has already going the WGLC, explicitly calls o=
ut the use of nonce as part of the best practices.=C2=A0 OAuth 2.1 should d=
o no less.


=C2=A0


The 9.7 language that Aaron proposed was the result of many people'=
;s contributions and a vigorous discussion.=C2=A0 Let's publish the nex=
t version of 2.1 with that language intact, as I believe it represents at l=
east a local point of hard-won consensus.=C2=A0 Let's get that language=
 into the record of drafts.


=C2=A0


There's always time to debate it and change it later in subsequent=
 drafts, but let's not now lose what it took a lot of effort to achieve=
.


=C2=A0


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


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


=C2=A0


-----Original Message-----


From: Nov Matake <matake@gmail.com> 


Sent: Thursday, May 14, 2020 3:18 AM


To: Torsten Lodderstedt <torsten@lodderstedt.net>


Cc: OAuth WG <o=
auth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>


Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1


=C2=A0


There is no specific mechanism right now.


But future developers won=E2=80=99t be able to read the reason why the=
 extension point is given only for confidential clients.

=C2=A0




On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> w=
rote:


=C2=A0


Are you aware of any suitable mechanism? I=E2=80=99m asking since from=
 my perspective this clause is mainly intended to allow existing OpenID Con=
nect deployments to use nonce instead of PKCE in combination with OAuth 2.1=
. It=E2=80=99s a compromise. I think we should not encourage others to inve=
nt their own OAuth security mechanisms. 


=C2=A0




On 14. May 2020, at 09:37, Nov Matake <matake@gmail.com> wrote:

=C2=A0


Hi,


=C2=A0


Why not allowing public clients use "other suitable mechanisms=E2=
=80=9D then?


OAuth WG can allow both type of clients do so, then OIDF will define n=
once as the alternative only for confidential clients.


=C2=A0




2020/05/14 15:56=E3=
=80=81Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc=
.ietf.org>=E3=81=
=AE=E3=83=A1=E3=83=BC=E3=83=AB:


=C2=A0


Hi all,


=C2=A0


I would also like to thank everybody for the substantial discussion.=
=C2=A0 


=C2=A0


The proposed change for Section 4.1.2.1 works for me (as already state=
d). I=E2=80=99m not fully comfortable with the proposed change for Section =
9.7 for the following reasons:


=C2=A0


- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of P=
KCE instead of requiring it (with a well-defined exception).<=
/pre>

- Given the latest findings re nonce I don=E2=80=99t feel comfortable =
with recommending any mechanism that this WG is not responsible for and thu=
s did not conduct the security threat analysis for. I think the better way =
for us as WG is to define the extension point for other mechanisms. The Ope=
nID Foundation (or any other body) can then fill in and issue a statement t=
hat nonce (or another suitable mechanism) fulfils the requirements of the e=
xtension point. 


=C2=A0


Based on this considerations, I propose the following text for Section=
 9.7:


=C2=A0


Clients MUST prevent injection (replay) of authorization codes into 


the authorization response by attackers. Public clients MUST use the <=
u>


"code_challenge=E2=80=9D with a transaction-specific value that i=
s securely 


bound to the client and the user agent in which the transaction was 


started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=
=80=9D in the 


same way or other suitable mechanisms to mitigate authorization code <=
u>


injection.


=C2=A0


This text follows the logic in Section 4.1.2.1 and allows use of the n=
once for confidential clients.


=C2=A0


best regards,


Torsten. 


=C2=A0




On 12. May 2020, at 02:21, Mike Jones <Michael.Jones=3D40=
microsoft.com@dmarc.ietf.org> wrote:


=C2=A0


That works for me.=C2=A0 Thanks all for the useful back-and-forth that=
 got us to this point of clarity.=C2=A0 I suspect many of us learned things=
 along the way; I know that I did!


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=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 -- Mike


=C2=A0


From: Aaron Parecki <aaron@parecki.com>


Sent: Monday, May 11, 2020 4:55 PM


To: OAuth WG <o=
auth@ietf.org>


Cc: Neil Madden <neil.madden@forgerock.com>; Mike Jones 

<M=
ichael.Jones@microsoft.com>


Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1


=C2=A0


Thank you Neil.


=C2=A0


To address Mike's concerns in the previous threads, I would like t=
o also update section 9.7 with the following text:


=C2=A0


Clients MUST prevent injection (replay) of authorization codes into 


the authorization response by attackers. The use of the =



`code_challenge` parameter is RECOMMENDED to this end. For <=
/u>


confidential clients, the OpenID Connect `nonce` parameter and ID <=
/u>


Token Claim {{OpenID}} MAY be used instead of or in addition to the 


`code_challenge` parameter for this purpose. The `code_challenge` <=
/u>


or OpenID Connect `nonce` value MUST be transaction-specific and 


securely bound to the client and the user agent in which the transacti=
on was started.


=C2=A0


This change better clarifies the specific circumstances under which th=
e "nonce" parameter is sufficient to protect against authorizatio=
n code injection.


=C2=A0


Aaron Parecki


=C2=A0


On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.madden@forgerock.com>=
 wrote:


I am happy with this proposed wording. Thanks for updating it.<=
u>


=C2=A0


=E2=80=94 Neil


=C2=A0


=C2=A0


On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> wrote:=



=C2=A0


Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! 


=C2=A0


We would like to propose the following text, which is a slight variati=
on from the text Neil proposed. This would replace the paragraph in 4.1.2.1=
 (https://tools.ietf.org/html/draft-parecki-oaut=
h-v2-1-02#section-4.1.2.1) that begins with "If the client does no=
t send the "code_challenge" in the request..."=



=C2=A0


"An AS MUST reject requests without a code_challenge from public =
clients, and MUST reject such requests from other clients unless there is r=
easonable assurance that the client mitigates authorization code injection =
in other ways.. See section 9.7 for details."


=C2=A0


Section 9.7 is where the nuances of PKCE vs nonce are described.


=C2=A0


As Neil described, we believe this will allow ASs to support both OAut=
h 2.0 and 2.1 clients simultaneously. The change from Neil's text is th=
e clarification of which threats, and changing to MUST instead of SHOULD. T=
he "MUST...unless" is more specific than "SHOULD", and =
since we are already describing the explicit exception to the rule, it'=
s more clear as a MUST here.


=C2=A0


Aaron Parecki


=C2=A0


=C2=A0


=C2=A0


=C2=A0


_______________________________________________


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/listinfo/oauth




_______________________________________________


OAuth mailing 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








_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth


























=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


3D""=
=E1=90=A7


--000000000000a30a3c05a693fff9--


From nobody Wed May 27 07:09:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B4E3A0B42 for ; Wed, 27 May 2020 07:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7b-iMjRMNUD for ; Wed, 27 May 2020 07:09:16 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E129C3A0B41 for ; Wed, 27 May 2020 07:09:15 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id s8so24086650wrt.9 for ; Wed, 27 May 2020 07:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=mNdC4UDJNDCxZOSS8G9VXuPy5SrPizNcQkftwebqSQo=; b=KnMMizNQHZvoUaeOBPKPwm4HSsl+IdyMGm7LcQ/CEoQd/RNKeHnnHmBsUReXvbmCqc wUy9AH4gvTz/XKXqwqYhp8IFl0+NfzJlAap60v3BwtpoP3cNg11MsxklWq39pVBvldEp F9fLsnjmgjpVo4RPpadMIDXJSxK0C6mR+/xA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mNdC4UDJNDCxZOSS8G9VXuPy5SrPizNcQkftwebqSQo=; b=eNUu1yY1WlnF0blHdRQSgQaA686RnBngeN5SV5kHblL9Oqjs2GDznAl01boLpxplTe cKM9KoZbq3j58Xt6mLvMF25RowXyM8+zi+2iB9S1enUfaoh/f3Wd600PXzZbPJqoPWMT EGQwoo1EAcKP5jhmakwIFx3JuKyQdlP4kxFhdS3RsnWLMGVsNyq6CPKxljGJ+fp+VjBH VAr7vWc2nwgsOTLOMPggCDbSvGYKx5R+0ObvBozh12KqoObjk+KWdYQ9IuTO31athZZ9 SFhc5h4u2sd+B5jdn9bCBVrV9BUXi46PBZAwgVQfgw0mU3UFELqhlYjdg42KjxQwXeh4 Opjw==
X-Gm-Message-State: AOAM530ovNDZDcFlwUG/EioPWNgyX1kzrTiEcPI13Wyn8pSe+9fULOab 0oDF2RmH9FNkT5Dk6h4PEyDMTtIk0Kmht1lsdLHXdItEf10=
X-Google-Smtp-Source: ABdhPJwn9HTbokE82jc4f6czsy04vTlYP+8chrlRt/BW91YkIbrdpwX4XJwpPqF9/Hmgt1KDXhDSkfzbkLezslvMYeg=
X-Received: by 2002:adf:f28f:: with SMTP id k15mr22198038wro.283.1590588550079;  Wed, 27 May 2020 07:09:10 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Francis Pouatcha 
Date: Wed, 27 May 2020 10:08:59 -0400
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000082fb2005a6a1c168"
Archived-At: 
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 14:09:19 -0000

--00000000000082fb2005a6a1c168
Content-Type: text/plain; charset="UTF-8"

>
>
>
> Message: 1
> Date: Tue, 26 May 2020 09:03:16 +0300
> From: Vladimir Dzhuvinov 
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
> Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2id.com>
> Content-Type: text/plain; charset="utf-8"
>
> My understanding of the branding concept was to present different UIs to
> resource owners during login and authorization, while keeping the OP /
> AS the same, meaning identical issuer. In a spec it would be helpful to
> spell out what branding means (and what not).
>
Let us call this varian the AS-Brand.
As an RO, I sign in for AS-Brand-A and my token is usable under the context
of AS-Brand-B because both share the same issuer.  This kills
transparency at the RO site.

I support: One AS-Brand <-> One Issuer.

Regards
/Francis

>
> Regarding a token being issued for "personal" vs "business" and
> confusion - the usage of the token is normally defined by its scope and
> audience (RS) and if this rule is observed (and it's not relied solely
> on the issuer URI for that) then clients shouldn't get confused here.
>
> Vladimir
>
> On 23/05/2020 06:26, Francis Pouatcha wrote:
> > - I will go for Option 1 even if we have the same runtime instance
> > producing tokens under different?issuer uris.
> > - Option 2 might expose security risk as many clients rely on
> > the?issuer to associate the? token with authorization context. By no
> > way shall a token issued for "personal" be valid for "business".
> > Therefore considering?the?use of the?same issuer here might lead to
> > confusion at the?RP.
> > - In order to avoid confusion, AS must make?sure each "brand"
> > uses?separated key material to produce the token.
> >
> > BTW:
> > The term brand as used in the context of most Open Banking initiatives
> > refers to entities consuming the Interface provided by TPPs (Third
> > Party Providers).. TPPs play the roles of RPs in the oAuth2 context.
> >
> > Unless I misunderstood this thread we are using a brand here to refer
> > to an AS virtual host (issuer-uri).
> >
> > Going forward, we need?to?agree on choosing another term to refer to
> > issuers, and leave the term "Brand" for consumers of TPP-interfaces.
> >
> > The core brand problem we will be facing in open banking is for having
> > the AS display the "consumer-brand" logo to the RO in the consent screen.
> >
> >
> >     >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov
> >     > wrote:
> >     >>
> >     >> With that said it makes sense to devise a structure which can
> >     accommodate UI driven as well as automatic choice.
> >     >>
> >     >>? ? ? ? The UI driven chooser will need a human readable
> >     description and other UI hints. This can work for instance with
> >     "classic" OIDC Discovery.
> >     >>
> >     >>? ? ? ? The "auto" chooser will need some sort of an ID. For a
> >     bank chooser this means providing the issuer URI and an optional
> >     brand ID and both must get registered together. Or, one could
> >     define a standard brand ID (label) for banking operations and if
> >     the "alternative_authorization_endpoints" is present look for it
> >     in the structure, else fall back to the default
> >     "authorization_endpoint".
> >     >> Here is one possible layout which has IDs and UI hints:
> >     >>
> >     >> {
> >     >>? ?...
> >     >>? ?"alternative_authorization_endpoints": {
> >     >>? ? ?"banking": {
> >     >>? ? ? ?"authorization_endpoint":
> >     >> "https://loadsamoney/business/auth"
> >     >> ,
> >     >>? ? ? ?"description": "loadsmoney business banking customers",
> >     >>? ? ? ?"logo_url":
> >     >> "https://loadsamoney/business/logo.png"
> >     >>
> >     >>? ? ?},
> >     >>? ? ?"personal": {
> >     >>? ? ? ?"authorization_endpoint":
> >     >> "https://loadsamoney/consumer/auth"
> >     >> ,
> >     >>? ? ? ?"description": "loadsmoney personal customers",
> >     >>? ? ? ?"logo_url":
> >     >> "https://loadsamoney/consumer/logo.png"
> >     >>
> >     >>? ? ?}
> >     >>? ?}
> >     >> }
> >     >>
> >     >>
> >     >>
> >     >> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
> >     >>> I think an id or label per endpoint set would be needed to
> >     determine the set of endpoints to be used by a certain client.
> >     >>>
> >     >>> On the conceptual side, I?m asking myself how the complete
> >     process is supposed to work. Who is deciding what issuer/endpoint
> >     set combination to use. I assume in an open banking scenario,
> >     there will always be some kind of bank chooser. Will this chooser
> >     provide the client with issuer and brand id?
> >     >>>
> >     >>>
> >     >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov
> >     >
> >     >>>>? wrote:
> >     >>>>
> >     >>>> A mapping like the one you propose can definitely work. Since
> >     the user will be making the choice which endpoint to take with the
> >     client app, having the logo_uri is a good idea. If the branded
> >     endpoints differ somehow in policy one could also allow inclusion
> >     of the op_policy_uri and op_tos_uri params from Discovery.
> >     >>>>
> >     >>>>
> >     >>>>
> >
> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
> >     >>>>
> >     >>>>
> >     >>>> Vladimir
> >     >>>>
> >     >>>> On 20/05/2020 19:16, Joseph Heenan wrote:
> >     >>>>
> >     >>>>> Thanks for your thoughts Vladimir!
> >     >>>>>
> >     >>>>> The client_id based solution I wasn?t previously aware of -
> >     unfortunately it doesn?t solve the problem for app2app, as the
> >     mobile OS selects the app to use based purely on the URL (and in
> >     at least the iOS case will not offer the user a choice if multiple
> >     apps claim to handle the same url).
> >     >>>>>
> >     >>>>> I think some kind of mapping like you suggest will work and
> >     fallback, I wonder about a structure in the authorization server
> >     metadata something like this:
> >     >>>>>
> >     >>>>> {
> >     >>>>>? ?...
> >     >>>>>? ?"alternative_authorization_endpoints": [
> >     >>>>>? ? ?{
> >     >>>>>? ? ? ?"authorization_endpoint":
> >     >>>>> "https://loadsamoney/business/auth"
> >     >>>>> ,
> >     >>>>>? ? ? ?"description": "loadsmoney business banking customers",
> >     >>>>>? ? ? ?"logo_url":
> >     >>>>> "https://loadsamoney/business/logo.png"
> >     >>>>>
> >     >>>>>? ? ?},
> >     >>>>>? ? ?{
> >     >>>>>? ? ? ?"authorization_endpoint":
> >     >>>>> "https://loadsamoney/consumer/auth"
> >     >>>>> ,
> >     >>>>>? ? ? ?"description": "loadsmoney personal customers",
> >     >>>>>? ? ? ?"logo_url":
> >     >>>>> "https://loadsamoney/consumer/logo.png"
> >     >>>>>
> >     >>>>>? ? ?}
> >     >>>>>? ?]
> >     >>>>> }
> >     >>>>>
> >     >>>>> And as you say, the existing authorization_endpoint can be a
> >     fallback for clients that are unaware of the new spec or prefer
> >     the simpler option of just using a single authorization endpoint.
> >     Supporting the new spec would allow a better UX though so there?s
> >     advantages to client to do so.
> >     >>>>>
> >     >>>>>> Speaking of mTLS, I'm not sure how the
> >     "mtls_endpoint_aliases" can be sensibly combined with the proposed
> >     multi-brand spec.
> >     >>>>>>
> >     >>>>>>
> >     >>>>> I think that particular part is not really an issue as mtls
> >     isn?t used at the authorization endpoint.
> >     >>>>>
> >     >>>>> Thanks
> >     >>>>>
> >     >>>>> Joseph
> >     >>>>>
> >     >>>>>
> >     >>>>>
> >     >>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov
> >     >
> >     >>>>>>? wrote:
> >     >>>>>>
> >     >>>>>> Hi Dave,
> >     >>>>>>
> >     >>>>>> In the absence of such a "multi-brand" spec we have tackled
> >     this issue in the past by letting the "brand" be encoded in the
> >     client_id. An alternative scenario is to do a "brand" lookup by
> >     client_id. Then let the AS render the "branded" authZ endpoint.
> >     >>>>>>
> >     >>>>>> You're probably aware the mTLS spec is allowing for
> >     endpoint aliases, so this is not the first time such as need has
> >     occurred:
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> https://tools.ietf.org/html/rfc8705#section-5
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> One could devise a similar JSON object with mappings
> >     "label" - "authorization_endpoint".
> >     >>>>>>
> >     >>>>>> Clients that are aware of the new spec will look it up,
> >     those that are not will fall back to the std
> "authorization_endpoint".
> >     >>>>>>
> >     >>>>>> Speaking of mTLS, I'm not sure how the
> >     "mtls_endpoint_aliases" can be sensibly combined with the proposed
> >     multi-brand spec.
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> Vladimir
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
> >     >>>>>>
> >     >>>>>>> Dear OAuth WG
> >     >>>>>>>
> >     >>>>>>> We have an issue in the OpenID FAPI Working Group that we
> >     believe affects the wider OAuth community.
> >     >>>>>>>
> >     >>>>>>> In summary: what is the recommended approach to discovery
> >     (RFC8414) for Authorization Servers who support multiple "brands" .
> >     >>>>>>>
> >     >>>>>>> If brands are completely separate, then it seems sensible
> >     that each brand must have its own `issuer` and therefore its own
> >     discovery document at the correct location (i.e. brand 1 would
> >     have an issuer of
> >     >>>>>>> "https://as/brand1" and a discovery document available at?
> >     https://as/.well-known/oauth-authorization-server/brand1
> >     >>>>>>> ).
> >     >>>>>>>
> >     >>>>>>> However in the real world it is not always so simple. We
> >     have many existing implementations in UK open banking that support
> >     multiple authorization endpoints. Here is an example (thanks to
> >     @Joseph Heenan )
> >     >>>>>>>
> >     >>>>>>>
> >     >>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking,
> >     one ?login page? for both business and personal customers.
> >     >>>>>>>>
> >     >>>>>>>> They have separate mobile apps for business/personal, and
> >     are required to support app2app. This means they will definitely
> >     be exposing multiple authorization endpoints (as there?s a 1:1
> >     mapping of authorization endpoints to mobile apps) - the choice is
> >     how they do this.
> >     >>>>>>>>
> >     >>>>>>>> Their choices are:
> >     >>>>>>>>
> >     >>>>>>>> 1. Multiple discovery endpoints (one for business, one
> >     for personal), each with a different authorization endpoint,
> >     multiple issuers (if their vendor allows this)
> >     >>>>>>>> 2. Single discovery endpoint, single issuer, multiple
> >     authorization endpoints listed in one discovery doc (one for
> >     business, one for personal) some of which are hardcoded by the 3rd
> >     party
> >     >>>>>>>> 3. Multiple discovery endpoints each with a different
> >     authorization endpoint, same issuer in all cases (breaks RFC8414
> >     and OIDC Discovery)
> >     >>>>>>>>
> >     >>>>>>> Option 3 is invalid and that leaves us with options 1 and 2.
> >     >>>>>>> Option 1 can be problematic as often it is in reality the
> >     same `issuer` behind the scenes.
> >     >>>>>>>
> >     >>>>>>> We would like to get feedback on this issue and
> >     potentially an extension to RFC8414 to allow the definition of
> >     multiple authorization endpoints.
> >     >>>>>>>
> >     >>>>>>> Thanks in advance
> >     >>>>>>>
> >     >>>>>>> Dave Tonge
> >     >>>>>>> Co-Chair FAPI WG
> >     >>>>>>> Open ID Foundation
> >     >>>>>>>
> >     >>>>>>>
> >     >>>>>>>
> >     >>>> --
> >     >>>> Vladimir Dzhuvinov
> >


-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

--00000000000082fb2005a6a1c168
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable





Message: 1

Date: Tue, 26 May 2020 09:03:16 +0300

From: Vladimir Dzhuvinov <vladimir@connect2id.com>

To: oauth@ietf.org<=
br>
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2=
id.com>

Content-Type: text/plain; charset=3D"utf-8"



My understanding of the branding concept was to present different UIs to
resource owners during login and authorization, while keeping the OP /

AS the same, meaning identical issuer. In a spec it would be helpful to

spell out what branding means (and what not).
Let us c=
all this varian the AS-Brand.=C2=A0
As an RO, I sign=C2=A0in for =
AS-Brand-A and my token is usable under the context of AS-Brand-B because b=
oth share the same issuer.=C2=A0 This kills transparency=C2=A0at the RO sit=
e.

I support: One AS-Brand <-> One Issuer.

Regards
/Francis


Regarding a token being issued for "personal" vs "business&q=
uot; and

confusion - the usage of the token is normally defined by its scope and

audience (RS) and if this rule is observed (and it's not relied solely<=
br>
on the issuer URI for that) then clients shouldn't get confused here.


Vladimir



On 23/05/2020 06:26, Francis Pouatcha wrote:

> - I will go for Option 1 even if we have the same runtime instance

> producing tokens under different?issuer uris.

> - Option 2 might expose security risk as many clients rely on

> the?issuer to associate the? token with authorization context. By no
> way shall a token issued for "personal" be valid for "b=
usiness".

> Therefore considering?the?use of the?same issuer here might lead to
> confusion at the?RP.

> - In order to avoid confusion, AS must make?sure each "brand"=
;

> uses?separated key material to produce the token.

>

> BTW:

> The term brand as used in the context of most Open Banking initiatives=


> refers to entities consuming the Interface provided by TPPs (Third

> Party Providers).. TPPs play the roles of RPs in the oAuth2 context.
>

> Unless I misunderstood this thread we are using a brand here to refer<=
br>
> to an AS virtual host (issuer-uri).

>

> Going forward, we need?to?agree on choosing another term to refer to
> issuers, and leave the term "Brand" for consumers of TPP-int=
erfaces.

>

> The core brand problem we will be facing in open banking is for having=


> the AS display the "consumer-brand" logo to the RO in the co=
nsent screen.

>

>

>=C2=A0 =C2=A0 =C2=A0>> On 22 May 2020, at 08:52, Vladimir Dzhuvin=
ov

>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>> =
wrote:

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> With that said it makes sense to devise a =
structure which can

>=C2=A0 =C2=A0 =C2=A0accommodate UI driven as well as automatic choice.<=
br>
>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The UI driven chooser will need a h=
uman readable

>=C2=A0 =C2=A0 =C2=A0description and other UI hints. This can work for i=
nstance with

>=C2=A0 =C2=A0 =C2=A0"classic" OIDC Discovery.

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The "auto" chooser will n=
eed some sort of an ID. For a

>=C2=A0 =C2=A0 =C2=A0bank chooser this means providing the issuer URI an=
d an optional

>=C2=A0 =C2=A0 =C2=A0brand ID and both must get registered together. Or,=
 one could

>=C2=A0 =C2=A0 =C2=A0define a standard brand ID (label) for banking oper=
ations and if

>=C2=A0 =C2=A0 =C2=A0the "alternative_authorization_endpoints"=
 is present look for it

>=C2=A0 =C2=A0 =C2=A0in the structure, else fall back to the default

>=C2=A0 =C2=A0 =C2=A0"authorization_endpoint".

>=C2=A0 =C2=A0 =C2=A0>> Here is one possible layout which has IDs =
and UI hints:

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> {

>=C2=A0 =C2=A0 =C2=A0>>? ?...

>=C2=A0 =C2=A0 =C2=A0>>? ?"alternative_authorization_endpoint=
s": {

>=C2=A0 =C2=A0 =C2=A0>>? ? ?"banking": {

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<=
br>
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/business=
/auth"

>=C2=A0 =C2=A0 =C2=A0>> ,

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads=
money business banking customers",

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":

>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/busi=
ness/logo.png"

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>>? ? ?},

>=C2=A0 =C2=A0 =C2=A0>>? ? ?"personal": {

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<=
br>
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/consumer=
/auth"

>=C2=A0 =C2=A0 =C2=A0>> ,

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads=
money personal customers",

>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":

>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/cons=
umer/logo.png"

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>>? ? ?}

>=C2=A0 =C2=A0 =C2=A0>>? ?}

>=C2=A0 =C2=A0 =C2=A0>> }

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> On 22/05/2020 09:59, Torsten Lodderstedt w=
rote:

>=C2=A0 =C2=A0 =C2=A0>>> I think an id or label per endpoint se=
t would be needed to

>=C2=A0 =C2=A0 =C2=A0determine the set of endpoints to be used by a cert=
ain client.

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> On the conceptual side, I?m asking mys=
elf how the complete

>=C2=A0 =C2=A0 =C2=A0process is supposed to work. Who is deciding what i=
ssuer/endpoint

>=C2=A0 =C2=A0 =C2=A0set combination to use. I assume in an open banking=
 scenario,

>=C2=A0 =C2=A0 =C2=A0there will always be some kind of bank chooser. Wil=
l this chooser

>=C2=A0 =C2=A0 =C2=A0provide the client with issuer and brand id?

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>>> On 22. May 2020, at 08:10, Vladimi=
r Dzhuvinov

>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><=
br>
>=C2=A0 =C2=A0 =C2=A0>>>>? wrote:

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> A mapping like the one you propose=
 can definitely work. Since

>=C2=A0 =C2=A0 =C2=A0the user will be making the choice which endpoint t=
o take with the

>=C2=A0 =C2=A0 =C2=A0client app, having the logo_uri is a good idea. If =
the branded

>=C2=A0 =C2=A0 =C2=A0endpoints differ somehow in policy one could also a=
llow inclusion

>=C2=A0 =C2=A0 =C2=A0of the op_policy_uri and op_tos_uri params from Dis=
covery.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0ht=
tps://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> On 20/05/2020 19:16, Joseph Heenan=
 wrote:

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks for your thoughts Vladi=
mir!

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> The client_id based solution I=
 wasn?t previously aware of -

>=C2=A0 =C2=A0 =C2=A0unfortunately it doesn?t solve the problem for app2=
app, as the

>=C2=A0 =C2=A0 =C2=A0mobile OS selects the app to use based purely on th=
e URL (and in

>=C2=A0 =C2=A0 =C2=A0at least the iOS case will not offer the user a cho=
ice if multiple

>=C2=A0 =C2=A0 =C2=A0apps claim to handle the same url).

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> I think some kind of mapping l=
ike you suggest will work and

>=C2=A0 =C2=A0 =C2=A0fallback, I wonder about a structure in the authori=
zation server

>=C2=A0 =C2=A0 =C2=A0metadata something like 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>>>>>? ?"alternative_authorizat=
ion_endpoints": [

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp=
oint":

>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo=
ney/business/auth"

>=C2=A0 =C2=A0 =C2=A0>>>>> ,

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":=
 "loadsmoney business banking customers",

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://load=
samoney/business/logo.png"

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?},

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp=
oint":

>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo=
ney/consumer/auth"

>=C2=A0 =C2=A0 =C2=A0>>>>> ,

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":=
 "loadsmoney personal customers",

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://load=
samoney/consumer/logo.png"

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?}

>=C2=A0 =C2=A0 =C2=A0>>>>>? ?]

>=C2=A0 =C2=A0 =C2=A0>>>>> }

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> And as you say, the existing a=
uthorization_endpoint can be a

>=C2=A0 =C2=A0 =C2=A0fallback for clients that are unaware of the new sp=
ec or prefer

>=C2=A0 =C2=A0 =C2=A0the simpler option of just using a single authoriza=
tion endpoint.

>=C2=A0 =C2=A0 =C2=A0Supporting the new spec would allow a better UX tho=
ugh so there?s

>=C2=A0 =C2=A0 =C2=A0advantages to client to do so.

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm =
not sure how the

>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c=
ombined with the proposed

>=C2=A0 =C2=A0 =C2=A0multi-brand spec.

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> I think that particular part i=
s not really an issue as mtls

>=C2=A0 =C2=A0 =C2=A0isn?t used at the authorization endpoint.

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> Joseph

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20 May 2020, at 16:07, =
Vladimir Dzhuvinov

>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><=
br>
>=C2=A0 =C2=A0 =C2=A0>>>>>>? wrote:

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Hi Dave,

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> In the absence of such a &=
quot;multi-brand" spec we have tackled

>=C2=A0 =C2=A0 =C2=A0this issue in the past by letting the "brand&q=
uot; be encoded in the

>=C2=A0 =C2=A0 =C2=A0client_id. An alternative scenario is to do a "=
;brand" lookup by

>=C2=A0 =C2=A0 =C2=A0client_id. Then let the AS render the "branded=
" authZ endpoint.

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> You're probably aware =
the mTLS spec is allowing for

>=C2=A0 =C2=A0 =C2=A0endpoint aliases, so this is not the first time suc=
h as need has

>=C2=A0 =C2=A0 =C2=A0occurred:

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> https:=
//tools.ietf.org/html/rfc8705#section-5

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> One could devise a similar=
 JSON object with mappings

>=C2=A0 =C2=A0 =C2=A0"label" - "authorization_endpoint&qu=
ot;.

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Clients that are aware of =
the new spec will look it up,

>=C2=A0 =C2=A0 =C2=A0those that are not will fall back to the std "=
authorization_endpoint".

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm =
not sure how the

>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c=
ombined with the proposed

>=C2=A0 =C2=A0 =C2=A0multi-brand spec.

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Vladimir

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20/05/2020 15:07, Dave =
Tonge wrote:

>=C2=A0 =C2=A0 =C2=A0>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dear OAuth WG

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> We have an issue in th=
e OpenID FAPI Working Group that we

>=C2=A0 =C2=A0 =C2=A0believe affects the wider OAuth community.

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> In summary: what is th=
e recommended approach to discovery

>=C2=A0 =C2=A0 =C2=A0(RFC8414) for Authorization Servers who support mul=
tiple "brands" .

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> If brands are complete=
ly separate, then it seems sensible

>=C2=A0 =C2=A0 =C2=A0that each brand must have its own `issuer` and ther=
efore its own

>=C2=A0 =C2=A0 =C2=A0discovery document at the correct location (i.e. br=
and 1 would

>=C2=A0 =C2=A0 =C2=A0have an issuer of

>=C2=A0 =C2=A0 =C2=A0>>>>>>> "https://as/brand1&qu=
ot; and a discovery document available at?

>=C2=A0 =C2=A0 =C2=A0https://as/.well-kno=
wn/oauth-authorization-server/brand1

>=C2=A0 =C2=A0 =C2=A0>>>>>>> ).

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> However in the real wo=
rld it is not always so simple. We

>=C2=A0 =C2=A0 =C2=A0have many existing implementations in UK open banki=
ng that support

>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints. Here is an exampl=
e (thanks to

>=C2=A0 =C2=A0 =C2=A0@Joseph Heenan )

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Bank ?loadsamoney?=
 has one idp and, for internet banking,

>=C2=A0 =C2=A0 =C2=A0one ?login page? for both business and personal cus=
tomers.

>=C2=A0 =C2=A0 =C2=A0>>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>>> They have separate=
 mobile apps for business/personal, and

>=C2=A0 =C2=A0 =C2=A0are required to support app2app. This means they wi=
ll definitely

>=C2=A0 =C2=A0 =C2=A0be exposing multiple authorization endpoints (as th=
ere?s a 1:1

>=C2=A0 =C2=A0 =C2=A0mapping of authorization endpoints to mobile apps) =
- the choice is

>=C2=A0 =C2=A0 =C2=A0how they do this.

>=C2=A0 =C2=A0 =C2=A0>>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Their choices are:=


>=C2=A0 =C2=A0 =C2=A0>>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 1. Multiple discov=
ery endpoints (one for business, one

>=C2=A0 =C2=A0 =C2=A0for personal), each with a different authorization =
endpoint,

>=C2=A0 =C2=A0 =C2=A0multiple issuers (if their vendor allows this)

>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 2. Single discover=
y endpoint, single issuer, multiple

>=C2=A0 =C2=A0 =C2=A0authorization endpoints listed in one discovery doc=
 (one for

>=C2=A0 =C2=A0 =C2=A0business, one for personal) some of which are hardc=
oded by the 3rd

>=C2=A0 =C2=A0 =C2=A0party

>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 3. Multiple discov=
ery endpoints each with a different

>=C2=A0 =C2=A0 =C2=A0authorization endpoint, same issuer in all cases (b=
reaks RFC8414

>=C2=A0 =C2=A0 =C2=A0and OIDC Discovery)

>=C2=A0 =C2=A0 =C2=A0>>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 3 is invalid an=
d that leaves us with options 1 and 2.

>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 1 can be proble=
matic as often it is in reality the

>=C2=A0 =C2=A0 =C2=A0same `issuer` behind the scenes.

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> We would like to get f=
eedback on this issue and

>=C2=A0 =C2=A0 =C2=A0potentially an extension to RFC8414 to allow the de=
finition of

>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints.

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> Thanks in advance

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dave Tonge

>=C2=A0 =C2=A0 =C2=A0>>>>>>> Co-Chair FAPI WG

>=C2=A0 =C2=A0 =C2=A0>>>>>>> Open ID Foundation

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> --

>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir Dzhuvinov

>

-- 
<=
div>
Francis Pouatcha
Co-Founder and Te=
chnical Lead at adorys
=



--00000000000082fb2005a6a1c168--


From nobody Wed May 27 10:17:10 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D752E3A0F55 for ; Wed, 27 May 2020 10:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.378
X-Spam-Level: 
X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIDLDZSbkQSe for ; Wed, 27 May 2020 10:17:07 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CE53A0F4F for ; Wed, 27 May 2020 10:17:06 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d59 with ME id jtH32200B4FMSmm03tH3is; Wed, 27 May 2020 19:17:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 27 May 2020 19:17:04 +0200
X-ME-IP: 86.238.65.197
To: oauth 
From: Denis 
Message-ID: <57405c52-8356-62dd-e242-f075882eef57@free.fr>
Date: Wed, 27 May 2020 19:17:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------E70E551A78284D113F8DBE93"
Content-Language: en-GB
Archived-At: 
Subject: [OAUTH-WG] Comments on OAuth 2.0 Rich Authorization Requests (draft-ietf-oauth-rar-01)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 17:17:09 -0000

This is a multi-part message in MIME format.
--------------E70E551A78284D113F8DBE93
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

This document states that the "scope" parameter used to specify the 
requested scope of an access token
is only "sufficient to implement static scenarios and coarse-grained 
authorization requests".

The intent of this draft is to specify "fine-grained authorization 
requirements", such as "please let me make
a payment with the amount of 45 Euros" or "please give me read access to 
folder A and write access to file X".

The proposed draft presents some similarities with a capability model 
where the holder of an access token is given
the right by an AS to perform some operation(s) on an object through the 
content of the access token.

Such an approach has privacy issues which are currently not documented 
in the Privacy Considerations section.

The AS would be in a position to know, not only which resources servers 
are going to be accessed, but also
what kind of operations are going to be performed by its clients on the 
resource servers. With such an approach,
ASs will have the knowledge of every operation that is likely to be 
performed by a user on every RS.

As a consequence, the AS would also be in a position to trace the 
actions performed by its users on the resources servers
with which it has a relationship.

Other approaches allowingto specify "fine-grained authorization 
requirements", that are more "privacy friendly"
should be considered to address the initial problem.


ADDITIONAL ARCHITECTURAL COMMENT

OAuth initially assumed a static relationship between clients, 
authorization servers and resource servers.

The original model for OAuth was making the assumption that the AS and 
the RS had a strong bilateral relationship.

A key question is whether such strong relationship will be maintained 
for ever or whether it will be allowed to perform
some evolutions of this relationship.

In order to respect the privacy of the users, there is the need to 
encompass other scenarios. One of these scenarios is
that the AS and the RS do not need any longer to have such a strong 
relationship. In terms of trust relationships, a RS
simply needs to trust the access tokens issued by an AS. The AS does 
have any more a "need to know" of all the RSs
that are accepting its access tokens. This would be a major 
simplification of the current global architecture.

oauth-security-topics states:

       The privileges associated with an access token SHOULD be
    restricted to the minimum required for the particular
       application or use case.

This means that the client should be able to select by itself the claims 
it would like to be placed into an access token
with respect to the operations it is willing to perform on a RS.

As long as only the scope request parameter will be usable in an access 
token request to select the claims to be placed
into an access token, it will not be possible to remove this strong 
relationship.

Denis


--------------E70E551A78284D113F8DBE93
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    

    

    

        This document states that the "scope" parameter used to specify
        the
        requested scope of an access token 

        is only "sufficient to implement static
        scenarios and coarse-grained authorization requests".

        

        The intent of this draft is to specify "fine-grained
        authorization
        requirements", such as "please let me make 

        a payment with the amount
        of 45 Euros" or "please give me read access to folder A and
        write
        access to file X".

        

        The proposed draft presents some similarities with a capability
        model where the
        holder of an access token is given 

        the right by an AS to perform some
        operation(s) on an object through the content of the access
        token.

    

        Such an approach has privacy issues which are currently not
        documented in the
        Privacy Considerations section.

        

        The AS would be in a position to know, not only which resources
        servers are
        going to be accessed, but also 

        what kind of operations are going to be
        performed by its clients on the resource servers. With such an
        approach, 

        ASs
        will have the knowledge of every operation that is likely to be
        performed by a
        user on every RS.

        

        As a consequence, the AS would also be in a position to trace
        the actions
        performed by its users on the resources servers 

        with which it has a
        relationship. 

        

        Other approaches allowing to specify "fine-grained authorization
          requirements", that are more "privacy friendly"

        should be
        considered to address the initial problem.

    

        

        ADDITIONAL ARCHITECTURAL COMMENT

      

    
OAuth initially assumed a static
        relationship between clients, authorization servers and resource
        servers.

      

    
The original model for OAuth was making the
        assumption that the AS and the RS
        had a strong bilateral relationship.

        

        A key question is whether such strong relationship will be
        maintained for ever
        or whether it will be allowed to perform 

        some evolutions of this relationship.

        

        In order to respect the privacy of the users, there is the need
        to encompass
        other scenarios. One of these scenarios is 

        that the AS and the RS do not need
        any longer to have such a strong relationship. In terms of trust
        relationships, a RS 

        simply needs to trust the access tokens
        issued by an AS. The AS does have any more a "need to know" of
        all the
        RSs 

        that are accepting its access tokens. This would be a major
        simplification
        of the current global architecture.

    
oauth-security-topics
        states: 

      

    

      
  The privileges
          associated with an access token SHOULD be restricted to the
          minimum required for the particular 

            application or use case.

        

    

    

        This means that the client should be able to select by itself
        the claims it
        would like to be placed into an access token 

        with respect to the operations it
        is willing to perform on a RS.

        

        As long as only the scope request parameter will be usable in an
        access token
        request to select the claims to be placed 

        into an access token, it will not be
        possible to remove this strong relationship.

    
Denis

      

    

  


--------------E70E551A78284D113F8DBE93--


From nobody Wed May 27 10:20:36 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1823A09AB for ; Wed, 27 May 2020 10:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.378
X-Spam-Level: 
X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb_PXKEMbTU8 for ; Wed, 27 May 2020 10:20:33 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D383A0889 for ; Wed, 27 May 2020 10:20:31 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d59 with ME id jtLV2200Y4FMSmm03tLVF8; Wed, 27 May 2020 19:20:30 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 27 May 2020 19:20:30 +0200
X-ME-IP: 86.238.65.197
To: oauth 
From: Denis 
Message-ID: 
Date: Wed, 27 May 2020 19:20:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------9D2E07AF638E073C82EAC6B1"
Content-Language: en-GB
Archived-At: 
Subject: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 17:20:34 -0000

This is a multi-part message in MIME format.
--------------9D2E07AF638E073C82EAC6B1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

As indicated in the abstract:

    "This document introduces the ability to send request parameters in
    a JSON Web Token (JWT) instead,
       which allows the request to be signed with JSON Web Signature (JWS)".

This approach has a major consequence which is not indicated in the 
"Privacy Considerations section:
the AS will have the knowledge of these request parameters such as 
"please let me make a payment with the amount of 45 Euros"
or "please give me read access to folder A and write access to file X".

Such an approach has privacy issues which are currently not documented 
in the Privacy Considerations section.

The AS would be in a position to know, not only which resources servers 
are going to be accessed, but also what kind of operations
are going to be performed by its clients on the resource servers. With 
such an approach, ASs will have a deep knowledge of every
operation that can be performed by a user on every RS.

As a consequence, the AS would also be in a position to trace the 
actions performed by its users on the resources servers.

Other approaches that are more "privacy friendly" should be considered 
to address the initial problem.

Denis

PS. This email closely relates to the previous email sent on the WG 
mailing list with the following topic:
        Comments on OAuth 2.0 Rich Authorization Requests 
(draft-ietf-oauth-rar-01)


--------------9D2E07AF638E073C82EAC6B1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    As
        indicated in the abstract: 
    

    

      

            "This document introduces the ability to send request
            parameters in a JSON
            Web Token (JWT) instead, 

              which allows the request to be signed with JSON Web
            Signature (JWS)".

    

    

    
        This approach has a major consequence which is not indicated in
        the
        "Privacy Considerations section: 

        the AS will have the knowledge of these
        request parameters such as "please let me make a payment with
        the amount
        of 45 Euros"

        or "please give me read access to folder A and write
        access to file X".

        

      Such an
        approach has privacy issues which are currently not documented
        in the
        Privacy Considerations section.

        

        The AS would be in a position to know, not only which resources
        servers are
        going to be accessed, but also what kind of operations 

        are going to be
        performed by its clients on the resource servers. With such an
        approach, ASs
        will have a deep knowledge of every 

        operation that can be performed by a user
        on every RS.

        

        As a consequence, the AS would also be in a position to trace
        the actions
        performed by its users on the resources servers. 

      

      Other approaches that are more "privacy friendly" should
      be
      considered to address the initial problem.
    
Denis

        

      

    
PS. This email closely relates to the previous
        email sent on the WG mailing list with the following topic: 

               Comments on OAuth 2.0 Rich Authorization Requests
        (draft-ietf-oauth-rar-01)

      

    

  


--------------9D2E07AF638E073C82EAC6B1--


From nobody Fri May 29 14:50:46 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA13A0F21 for ; Fri, 29 May 2020 14:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TgpuBQ8zW5X for ; Fri, 29 May 2020 14:50:42 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC463A0B56 for ; Fri, 29 May 2020 14:50:42 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id z22so597047lfd.0 for ; Fri, 29 May 2020 14:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kEwEAwYDVD7PpY/sX9lJWECvsJzDNTIN1adx4J7gwXw=; b=BefBKogKQOUb6zdyFy5Ea8BqgDfEMBD/LCRqmeQA9nd96EI9uFVsqSam+20Rb2606U MsK4JXI4hADFFteY1KfuFmPqyoYff+MAvdBSz4CVaFJYnqScV0KDZwRozh/4hAoXidn6 SCQtGvoadGPesHvyi2uiy1ojHyI+LLN5tNV18Nl+A5pl67nYuvJ7KZx4s8UGhu9IVLza T71/Qi5kLtnGMnt1JoRhFD+RGywg7AVFUkmoQ15VnQHRr9xH+bB7E3hK0ISPiCN+9C5t +jqHPn4TLtpVjdRB0IBbI9C3WxEugmj8YsA8TqTTqd0uUoD5yQS7RAm9jftOfgGIIA9a q/Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kEwEAwYDVD7PpY/sX9lJWECvsJzDNTIN1adx4J7gwXw=; b=bS7JsRlVsD9xok0PJQzWUS75aXMGQ6G/+bRojd1A9iWHiy9JPbiVgwqTkLgeYzVHoZ V5oNiPybo6umHUNI+z+ZWYJ5PGj2Kmv6V+7Q+Po1J2kgflUuGNV6E+7sz6BjTbWbaLfJ Fg+BiG2ix9R5ddeXKIdz3VTrF7Zwu32BRBz8FdI5uS1loeyBQuMsefDKMNR+ZUVg+OhG i+1pkeJatnO6b9xFk4k4u9XNRMrhpNv1Z/Xglegd9yKbtCIoTrF/wjtFz8RUYYwFG/kf Uc49nC94HrUkVhHEQIfntljo+MlehAPQQCryhJoJEgoSHJEkBpKohRR5ckOIWLgIZYx8 BIhg==
X-Gm-Message-State: AOAM532hzeRyP4Pps8GCDUWdR7qwPBuGADepYIxaIBZqm29Bdwpsg+ie o25Bm8ZsEOy7Jifh9E8KwxHG04IsxjX/h/FpnixT7RI2qsVRLFXns14hx/9mvn8WCKR4PxVsmmF 8Ya6xwDebNDYSfA==
X-Google-Smtp-Source: ABdhPJy16V2Uxx7v9+9GDkJ53h8xbyKRF6Jwpnn5nX+dRlugSi7a/1Iu/OUwWefHR52Ja50EHSQVaRfRXmPwtQHo0MI=
X-Received: by 2002:a19:f518:: with SMTP id j24mr5436935lfb.11.1590789040040;  Fri, 29 May 2020 14:50:40 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 29 May 2020 15:50:13 -0600
Message-ID: 
To: Filip Skokan 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000a5920905a6d06ff2"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 21:50:45 -0000

--000000000000a5920905a6d06ff2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Apologies for the slow reply on this. No excuses other than life sometimes
happens.

`token_type` is maybe not the clearest extension point (and one I've
arguably misused in OAuth MTLS 
and the now defunct Token Binding
and admitted
to being on the fence about in the issue you linked to
). But it is the
extension point that was basically left in RFC 6749 to facilitate this
exact kind of thing (for MAC really but it's conceptually similar in that
it was an application level proof mechanism of sorts) . The text from RFC
6749 sec 7.1  is also
copied below. Note that a "client MUST NOT use an access token if it does
not understand the token type" so FWIW the client behaviours you describe
aren't in line with that.

It still seems to be that using DPoP token_type is the appropriate thing to
do and that it can be defined to account and allow for mixed token type
situations.  It would define that the DPoP authz scheme be used as the
authentication method to include the access token when making a protected
resource request. That definition can also include falling back to using
the Bearer authz scheme when/if so challenged by a protected resource.



  7.1 .  Access Token Typ=
es

   The access token type provides the client with the information
   required to successfully utilize the access token to make a protected
   resource request (along with type-specific attributes).  The client
   MUST NOT use an access token if it does not understand the token
   type.

   For example, the "bearer" token type defined in [RFC6750
] is utilized
   by simply including the access token string in the request:

     GET /resource/1 HTTP/1.1
     Host: example.com
     Authorization: Bearer mF_9.B5f-4.1JqM

   while the "mac" token type defined in [OAuth-HTTP-MAC
] is utilized
by
   issuing a Message Authentication Code (MAC) key together with the
   access token that is used to sign certain components of the HTTP
   requests:

     GET /resource/1 HTTP/1.1
     Host: example.com
     Authorization: MAC id=3D"h480djs93hd8",
                        nonce=3D"274312:dj83hs9s",
                        mac=3D"kDZvddkndxvhGRXZhvuDjEWhGeE=3D"

   The above examples are provided for illustration purposes only.
   Developers are advised to consult the [RFC6750
] and [OAuth-HTTP-MAC
]
   specifications before use.

   Each access token type definition specifies the additional attributes
   (if any) sent to the client together with the "access_token" response
   parameter.  It also defines the HTTP authentication method used to
   include the access token when making a protected resource request.



On Tue, May 19, 2020 at 7:20 AM Filip Skokan  wrote:

> This is a RE: to yesterday's interim meeting discussion, largely related
> to the first rollout step where we want to constrain refresh tokens but
> leave protected resource access intact.
>
> I'll start off with a case that I hope we can agree is absolutely
> necessary for DPoP to solve - that is constraining refresh tokens for
> browser based applications. Now, *do we see this as a secondary
> objective? I think it should be on par with access token constraining.* S=
PAs
> using code flow and having access to refresh tokens as means against the
> continuous browser efforts to cut down on storage access is a real case
> servers will be eventually forced to adopt.
>
> Since rollout for DPoP needs to begin with the AS and Client supporting i=
t
> (regardless what order i guess) there are going to be instances where the
> RS will be supporting both Bearer and DPoP at the same time.
>
> As discussed yesterday, the client shouldn't know/care and change its
> behaviour when it comes to using access tokens.
>
> *But what is the client behaviour we take for standard?* Because I can
> see two conflicting implementations in the wild
>
>    1. The client echoes the token_type it received from the token
>    endpoint as the authorization scheme
>       - (optionally) throws on unrecognized token type values
>    2. The client uses Bearer as a fixed authorization scheme and ignores
>    the token_type it received
>
> #2 is an implementation which I suspect has no idea about DPoP, but if
> extended to send DPoP headers (through various mechanism - library
> extensions or even manipulating the `XMLHttpRequest` prototype) will
>
>    - =F0=9F=8E=89 get the benefit of having its Refresh Tokens bound
>    - =F0=9F=8E=89 most likely continue to work with RSs that only support=
 Bearer
>    - =E2=9D=8C will cease to work with RSs that will adopt support for DP=
oP
>    because it'll be using the wrong scheme, that is unless (=F0=9F=8E=89)=
 RSs supporting
>    DPoP choose to suspend the requirement to use the new scheme and inste=
ad
>    depend on the presence of `cnf.jkt` as means to trigger DPoP validatio=
n. *Q:
>    is that an acceptable thing to do?*
>
> Arguably, client behaviour #1 is what a client should be using if it
> supports other schemes besides Bearer. But it may as well be the behaviou=
r
> of a client that has no clue about DPoP, right? Again, such client can be
> made to support DPoP in a SPA through manipulation of the XMLHttpRequest
> prototype, in which case the developer needs to do the same for
> the protected resource calls. But at this point the developer has to know
> which RS to apply DPoP to and which not - ergo - which to send Bearer vs.
> DPoP scheme to? The developer will have to write a whitelist of resource
> servers anyway - and there we get to the point where client has informati=
on
> and functionality that it shouldn't /need to/ have.
>
> Its great that we have token_type, authorization header schemes, etc...,
> but we don't seem have a well defined (or at least followed) behaviour fo=
r
> our clients around handling the token_type response values and their usag=
e.
>
> A developer has to resolve to navigate this monkey course unless the RS
> definition on the AS is aware of the fact that the RS does support DPoP, =
so
> that the issued token_type is always correct for the RS. So, *should we
> make that a recommended way of 'indicating' when to issue Bearer vs DPoP
> access tokens?*
>
> What else could we do that doesn't give more decision making to the
> clients so that the very first step - *Refresh Tokens get constrained* -
> is achieved* but Protected Resource access is unaffected?*
>
> Note that this was not "a thing" for mTLS because it continues to use the
> Bearer scheme (for better or worse) and it completely omits possible
> continuous rollout or discussing what are the signals the RS must use to
> require mTLS to be used), same for the abandoned OAuth 2.0 Token Binding
> draft (also continued to use the Bearer scheme).
>
> I suspect we have just this opportunity to fix token types and their use
> and if we can't, we'll have to resolve to abandon that extension point as
> one that doesn't support continued rollout of real sender constraining
> mechanism (e.g. http signatures in the future) and just continue using
> Bearer because in the end, given that RSs could be relying on the presenc=
e
> of the cnf claim to figure out the token's constraining mechanism, would
> that be such a bad thing?
>
> Put it the other way around. By introducing Bearer scheme, do we actually
> gain anything of value that can't be gained through other means?
>
> Note that this message didn't start with the goal of questioning the new
> scheme use, it just sort of landed there... My pedantic nature would love
> to see the new scheme and token_type extension point used as it was meant
> to be but I also recognize the many issues it brings that could be
> sidestepped by not introducing it in the first place, all without losing
> capabilities.
>
> Previous material on the topic
>
>    - https://github.com/danielfett/draft-dpop/issues/41, decision to
>    break backwards compatibility amongst the authors
>    - ML
>     thread,
>    in my opinion inconclusive, no consensus
>
>
> S pozdravem,
> *Filip Skokan*
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

--000000000000a5920905a6d06ff2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Apologies for the slow reply on this. No excuses othe=
r than life sometimes happens.

`token_type` is may=
be not the clearest extension point (and one I've arguably misused in O=
Auth MTLS and the now defunct Token Binding and adm=
itted to being on the fence about in the issue you linked to). Bu=
t it is the extension point that was basically left in RFC 6749 to facilita=
te this exact kind of thing (for MAC really but it's conceptually simil=
ar in that it was an application level proof mechanism of sorts) . The text=
 from RFC 6749 sec 7.1 is also copied below. Note that a "cl=
ient MUST NOT use an access token if it does not understand the token type&=
quot; so FWIW the client behaviours you describe aren't in line with th=
at. 

It still seems to be that using=C2=A0DPoP=
 token_type is the appropriate thing to do and that it can be defined to ac=
count and allow for mixed token type situations.=C2=A0 It would define that=
 the DPoP authz scheme be used as the authentication method to include the =
access token when making a protected resource request. That definition can =
also include falling back to using the Bearer authz scheme when/if so chall=
enged by a protected resource. 

=

  7.1.  Access Token Types
<=
/span>

   The access token type provides the client with the information
   required to successfully utilize the access token to make a protected
   resource request (along with type-specific attributes).  The client
   MUST NOT use an access token if it does not understand the token
   type.

   For example, the "bearer" token type defined in [RFC6750] is u=
tilized
   by simply including the access token string in the request:

     GET /resource/1 HTTP/1.1
     Host: example.com
     Authorization: Bearer mF_9.B5f-4.1JqM

   while the "mac" token type defined in [OAuth-HTTP-MAC=
] is utilized by
   issuing a Message Authentication Code (MAC) key together with the
   access token that is used to sign certain components of the HTTP
   requests:

     GET /resource/1 HTTP/1.1
     Host: example.com
     Authorization: MAC id=3D"h480djs93hd8",
                        nonce=3D"274312:dj83hs9s",
                        mac=3D"kDZvddkndxvhGRXZhvuDjEWhGeE=3D"

   The above examples are provided for illustration purposes only.
   Developers are advised to consult the [RFC6750] and [OAuth-HTTP-MAC=
]
   specifications before use.

   Each access token type definition specifies the additional attributes
   (if any) sent to the client together with the "access_token" r=
esponse
   parameter.  It also defines the HTTP authentication method used to
   include the access token when making a protected resource request.







<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000a5920905a6d06ff2--


From nobody Sat May 30 00:58:57 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3F3A07E6 for ; Sat, 30 May 2020 00:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONJE2u-6j4AO for ; Sat, 30 May 2020 00:58:53 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E1E3A07E1 for ; Sat, 30 May 2020 00:58:53 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 6AFEE6483 for ; Sat, 30 May 2020 07:58:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1590825530; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=+jL8hUBoszwTZ4ggxxrSAca6EypwY8ToOTvUW1FXPNQ=; b=pF2Hr7ITGvpcDRDQgC9SwArcCRjb0ofAWnWXiSe6TTQLDkZtBBOLwNzLfifFeGd/EMlYsd +huUiVtVX3kII9jNWgDilil9/OEY7TCXCqigF0l2JSIq1sxdZ+IpB3aGu3LofIIzZ1Z9fy e69R72lC0o9QOSt6ZMe6EdlPse7eMRk=
To: "oauth@ietf.org" 
From: Daniel Fett 
Message-ID: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
Date: Sat, 30 May 2020 09:58:49 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------38C5B8B49D9B7BBB3DA3E51E"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1590825530; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=+jL8hUBoszwTZ4ggxxrSAca6EypwY8ToOTvUW1FXPNQ=; b=e3A2UJM4cgRldx7gSoiylialsCyrORespkuRq2wjO7NAy9nwEmE2VaVHFpiI8kbf7QdIVF qYwL8tAMykC7gIUa3Tt0LV5zH735j+o9MwYlximXbYCw7bTfFW6kNyPrOCCvdQpUrySMaF a9EnboeSW+VhKtk7syb4ohTd8IfrqEA=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1590825530; a=rsa-sha256; cv=none; b=Fp8VNJF/HUHSEZwFdoVi4/Ot0FvxwSMwJ0ZfTm+8vt7jG2qFer7SYdhbqxXl4hwG8qgZyv B+Z8u7Tmkjr5sg2exz6Wn5stZbGUIA4bkL7E1r5wTeMN31DpvOHdP7UClyQU4v5d0MKzpv SKhWD57hSOpaJ1t81yP3RDMtcPzBBc0=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: [OAUTH-WG] Downgrade attacks on PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 07:58:56 -0000

This is a multi-part message in MIME format.
--------------38C5B8B49D9B7BBB3DA3E51E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi all,

Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE
[1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the
conclusion that we have two options:

*1. "Static" Solution*

For every client_id that is registered with an AS, the AS MUST either
always enforce the use of PKCE or always enforce the use of nonce.
Whether PKCE or nonce is enforced can be part of the client registration
or configured in other ways.

In other words: A single client is not allowed to switch between using
PKCE and using nonce.

Note that the client is allowed to use the respective other mechanism on
top of the enforced one.

Properties:

  * Easy to understand mitigation.
  * Implementation is mainly a new data field and a check in the
    authorization request.
  * Not compatible to deployments where clients sometimes use nonce and
    sometimes use PKCE with the same client_id. *
    ***

**

*2. "Dynamic" Solution*

Each AS that supports PKCE MUST check whether a code challenge is
contained in the authorization request. This information MUST be bound
to the code that is issued.

When a code arrives at the token endpoint, the AS MUST do the following
check:

 1. If there was a code_challenge in the authorization request for which
    this code was issued, there must be a code_verifier in the token
    request and it must be verified according to RFC7636. (This is no
    change from the current behavior in RFC7636.)
 2. If there was no code_challenge in the authorization request, any
    request to the token endpoint containing a code_verifier MUST be
    rejected.

Properties:

  * No change in behavior needed for properly implemented clients.
    Backwards compatible for all existing deployments.
  * Implementation is mainly some logic for the authorization endpoint,
    token endpoint, and a new data field in the authorization session
    maintained by the AS.
  * Slightly more complex to implement for the AS, maybe.

We would like to hear the feedback from the working group on these two
solutions before proceeding to propose wording for the affected documents.

[1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

-Daniel


--------------38C5B8B49D9B7BBB3DA3E51E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Hi all,

    

    


    

    
Aaron, Dick, Torsten and I today
      discussed the downgrade attacks on PKCE [1] and how to mitigate
      them in OAuth 2.1 and 2.0. We came to the conclusion that we have
      two options:

    


    

    
1. "Static" Solution

    


    

    
For every client_id that is registered
      with an AS, the AS MUST either always enforce the use of PKCE or
      always enforce the use of nonce. Whether PKCE or nonce is enforced
      can be part of the client registration or configured in other
      ways.

    


    

    
In other words: A single client is not
      allowed to switch between using PKCE and using nonce.

    

    


    

    
Note that the client is allowed to use
      the respective other mechanism on top of the enforced one.

    


    

    
Properties:

    

      
    
        
  • Easy to understand mitigation.
    
        
    • 
        
  • Implementation is mainly a new data field and a check in the
          authorization request.
    • 
        
  • Not compatible to deployments where clients sometimes use
          nonce and sometimes use PKCE with the same client_id. 
    
               
    • 
      

       
      
2. "Dynamic" Solution

      
Each AS that supports PKCE MUST check whether a code challenge
        is contained in the authorization request. This information MUST
        be bound to the code that is issued.

      
When a code arrives at the token endpoint, the AS MUST do the
        following check:

      
    
        
  1. If there was a code_challenge in the authorization request
          for which this code was issued, there must be a code_verifier
          in the token request and it must be verified according to
          RFC7636. (This is no change from the current behavior in
          RFC7636.)
    2. 
        
  2. If there was no code_challenge in the authorization request,
          any request to the token endpoint containing a code_verifier
          MUST be rejected.
    3. 
      

      
Properties:

      
    
        
  • No change in behavior needed for properly implemented
          clients. Backwards compatible for all existing deployments.
    
        
    • 
        
  • Implementation is mainly some logic for the authorization
          endpoint, token endpoint, and a new data field in the
          authorization session maintained by the AS.
    
        
    • 
        
  • Slightly more complex to implement for the AS, maybe.
    • 
      

    

    
We would like to hear the feedback from
      the working group on these two solutions before proceeding to
      propose wording for the affected documents.

    

    


    

    
[1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

    


    

    
-Daniel

    


    

  


--------------38C5B8B49D9B7BBB3DA3E51E--


From nobody Sat May 30 04:38:51 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756253A091A for ; Sat, 30 May 2020 04:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv1JnRfi8Fgo for ; Sat, 30 May 2020 04:38:48 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D90E3A0919 for ; Sat, 30 May 2020 04:38:47 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id x14so6796951wrp.2 for ; Sat, 30 May 2020 04:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0KtSMV91SIbCr/UUAsJv+UVdV2pGrx3eWSY8QYZGAw8=; b=Q2K+KgdZ3dQ597q25t9XZuH6Zmo7WPWzgWpdu/835Z5dWAa8V7jube/lV5P99RoEBP yS9r4YZgUpLjqIdkxP0VtJttsgKXaSrqCqgz+qt4an7QDD62mVomwS6Vry4yL494pgpy zRr5cgth73qTAp8UBaBp7vTZGhbVvkb8AzFMM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0KtSMV91SIbCr/UUAsJv+UVdV2pGrx3eWSY8QYZGAw8=; b=HlDxxGqonz5SSl7fhyKiYbssD2N/mYd+1GBqF3I9rUxWXTJpk3scVDWHpvpIS6938+ BbNEAwtpd8KLPr/RHc1b32e/JYotMdScMi26JCY/88m3LZHeSiQo5CdPbKHlXYl7BxYT lE2YvKdIM3W9U3RT6G86RiXrZX983+65zky5vnIzUEPuGlracxBJEOtZfdsNdpIasgnD RnseD08XREWGMsb18vG0zdvstZldh/h38ZZMGRQAJNJvg5dQYw1pN0MvN9idy19smK1f FnEV/K9a0qUp5HXmNJxUQCGV4L7teQJWbQjE1P3HvQMw0XhMc3vuiJi90+PplVXb+zqW jObA==
X-Gm-Message-State: AOAM531X3gL6Ff/tQLYjzDLR0BmNaZjb/AtAfLx6/azrJ/DurH8appTo M1unMhNx0L5bI9H7WYNznK0OKfTF96I=
X-Google-Smtp-Source: ABdhPJxsdGz4XYSyVDwsIHrVRyUs3ypM5ihZ/ymsTdZ03rHVJiQFHIKGrhKemfn7uD3zsTfA4TqDKw==
X-Received: by 2002:adf:df91:: with SMTP id z17mr12843396wrl.273.1590838726269;  Sat, 30 May 2020 04:38:46 -0700 (PDT)
Received: from [10.0.0.2] (214.249.143.150.dyn.plus.net. [150.143.249.214]) by smtp.gmail.com with ESMTPSA id l5sm3055942wml.27.2020.05.30.04.38.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2020 04:38:45 -0700 (PDT)
From: Neil Madden 
Message-Id: <9EDABAF3-0445-4F5B-9DA5-4B3C1BFEE4B4@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40117D3E-F962-4C2C-BE79-859DAAEF42B7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 30 May 2020 12:38:44 +0100
In-Reply-To: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
Cc: "oauth@ietf.org" 
To: Daniel Fett 
References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 11:38:50 -0000

--Apple-Mail=_40117D3E-F962-4C2C-BE79-859DAAEF42B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

We (ForgeRock) already support solution 1 as a configuration option, but =
I prefer solution 2 and have raised a ticket for us to implement it. For =
us at least it=E2=80=99s a trivial fix and seems more robust against =
configuration errors.

=E2=80=94 Neil

> On 30 May 2020, at 08:58, Daniel Fett  wrote:
>=20
> Hi all,
>=20
> Aaron, Dick, Torsten and I today discussed the downgrade attacks on =
PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the =
conclusion that we have two options:
>=20
> 1. "Static" Solution
>=20
> For every client_id that is registered with an AS, the AS MUST either =
always enforce the use of PKCE or always enforce the use of nonce. =
Whether PKCE or nonce is enforced can be part of the client registration =
or configured in other ways.
>=20
> In other words: A single client is not allowed to switch between using =
PKCE and using nonce.
>=20
> Note that the client is allowed to use the respective other mechanism =
on top of the enforced one.
>=20
> Properties:
> Easy to understand mitigation.
> Implementation is mainly a new data field and a check in the =
authorization request.
> Not compatible to deployments where clients sometimes use nonce and =
sometimes use PKCE with the same client_id.=20
> 2. "Dynamic" Solution
>=20
> Each AS that supports PKCE MUST check whether a code challenge is =
contained in the authorization request. This information MUST be bound =
to the code that is issued.
>=20
> When a code arrives at the token endpoint, the AS MUST do the =
following check:
>=20
> If there was a code_challenge in the authorization request for which =
this code was issued, there must be a code_verifier in the token request =
and it must be verified according to RFC7636. (This is no change from =
the current behavior in RFC7636.)
> If there was no code_challenge in the authorization request, any =
request to the token endpoint containing a code_verifier MUST be =
rejected.
> Properties:
>=20
> No change in behavior needed for properly implemented clients. =
Backwards compatible for all existing deployments.
> Implementation is mainly some logic for the authorization endpoint, =
token endpoint, and a new data field in the authorization session =
maintained by the AS.
> Slightly more complex to implement for the AS, maybe.
> We would like to hear the feedback from the working group on these two =
solutions before proceeding to propose wording for the affected =
documents.
>=20
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ =

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


--Apple-Mail=_40117D3E-F962-4C2C-BE79-859DAAEF42B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

We =
(ForgeRock) already support solution 1 as a configuration option, but I =
prefer solution 2 and have raised a ticket for us to implement it. For =
us at least it=E2=80=99s a trivial fix and seems more robust against =
configuration errors.

=E2=80=94 Neil



On 30 May 2020, at 08:58, Daniel Fett <fett@danielfett.de> =
wrote:


 =20

    
 =20
  

    
Hi all,

    

    


    

    
Aaron, Dick, Torsten and I today
      discussed the downgrade attacks on PKCE [1] and how to mitigate
      them in OAuth 2.1 and 2.0. We came to the conclusion that we have
      two options:

    


    

    
1. "Static" =
Solution

    


    

    
For every client_id that is =
registered
      with an AS, the AS MUST either always enforce the use of PKCE or
      always enforce the use of nonce. Whether PKCE or nonce is enforced
      can be part of the client registration or configured in other
      ways.

    


    

    
In other words: A single client is =
not
      allowed to switch between using PKCE and using nonce.
=

    

    


    

    
Note that the client is allowed to =
use
      the respective other mechanism on top of the enforced one.

    


    

    
Properties:

    

      
    
        
  • Easy to understand mitigation.
    
        
    • 
        
  • Implementation is mainly a new data field and a =
check in the
          authorization request.
    • 
        
  • Not compatible to deployments where clients =
sometimes use
          nonce and sometimes use PKCE with the same client_id. 
    
               
    • 
      

       
2. "Dynamic" =
Solution
Each AS that supports PKCE MUST check =
whether a code challenge
        is contained in the authorization request. This information MUST
        be bound to the code that is issued.
When a =
code arrives at the token endpoint, the AS MUST do the
        following check:

      
    
        
  1. If there was a code_challenge in the =
authorization request
          for which this code was issued, there must be a code_verifier
          in the token request and it must be verified according to
          RFC7636. (This is no change from the current behavior in
          RFC7636.)
    2. 
        
  2. If there was no code_challenge in the =
authorization request,
          any request to the token endpoint containing a code_verifier
          MUST be rejected.
    3. 
      
Properties:

      
    
        
  • No change in behavior needed for properly =
implemented
          clients. Backwards compatible for all existing deployments.
    
        
    • 
        
  • Implementation is mainly some logic for the =
authorization
          endpoint, token endpoint, and a new data field in the
          authorization session maintained by the AS.
    
        
    • 
        
  • Slightly more complex to implement for the AS, =
maybe.
    • 
      

    

    
We would like to hear the feedback =
from
      the working group on these two solutions before proceeding to
      propose wording for the affected documents.

    

    


    

    
[1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-no=
t/

    


    

    
-Daniel

    


    

  


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

=

--Apple-Mail=_40117D3E-F962-4C2C-BE79-859DAAEF42B7--


From nobody Sat May 30 13:55:32 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53F83A09C8 for ; Sat, 30 May 2020 13:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB0UhBnnR7uA for ; Sat, 30 May 2020 13:55:29 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839083A09C0 for ; Sat, 30 May 2020 13:55:29 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04UKtMJ8023463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 May 2020 16:55:24 -0400
Date: Sat, 30 May 2020 13:55:22 -0700
From: Benjamin Kaduk 
To: Denis 
Cc: oauth@ietf.org, Vittorio Bertocci 
Message-ID: <20200530205522.GV58497@kduck.mit.edu>
References:  <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 20:55:31 -0000

On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> Hi Benjamin,
> > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> >> Since then, I questioned myself how a client would be able to request an
> >> access token that would be
> >> *strictly compliant with this Profile*.
> > I don't understand why this is an interesting question to ask.  The access
> > token and interpretation thereof is (AIUI) generally seen as an internal
> > matter between AS and RS, with the client having no need to care about the
> > specifics.
> 
> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.

Sure.  But (in my understanding), in common usage, the contents and
interpretation of the access token is set by common agreement between AS
and RS, with the client serving only as a "dumb" channel for transporting
the token.  That is, we're providing a token format that an RS and AS can
agree to use, most likely for all tokens issued by the AS for that RS.  I
don't know of any existing mechanisms, or desire for such mechanisms by
deployments, for using a different token format for different tokens issued
by a given AS for a given RS.  Attempting to have the client provide input
that would affect such a mechanism seems like complexity with no market
demand; a "solution in search of a problem" as it were.  Is there some
pent-up demand among OAuth deployments that I'm not aware of?  I freely
admit to not being very on top of the broad spectrum of what's deployed...

> 1) A client may wish to obtain an Access Token that corresponds to this 
> Profile because, for example,
> this document mandates the "sub" claim to be present". Hence, the 
> content of the Access Token is not
> totally "/an internal matter between AS and RS/".
> 
> However, I have not understood how a client could request an Access 
> Token that corresponds to *_this_***Profile,
> since there is no mandatory parameter in the request (both the "scope" 
> parameter and the "resource" parameter are optional).
> 
> In the future, we could define _*another*_**Profile. Hence, there is the 
> same question:  How could a client request an Access Token
> that corresponds to *_that other_***Profile ?
> 
> 2) When getting a JWT,  how can the client make sure that the access 
> token it got is compliant with this Profile ?
> 
> RFC 8725 states in section 3.11 :
> 
>     3.11. Use Explicit Typing
>     Sometimes, one kind of JWT can be confused for another. If a
>     particular kind of JWT is subject to such confusion,
>     that JWT can include an explicit JWT type value, and the validation
>     rules can specify checking the type (...).
>     Explicit JWT typing is accomplished by using the "typ" Header
>     Parameter.
> 
> Wouldn't be wise to include an explicit JWT type value for JWTs 
> conformant to this Profile ?

In the model where the client is a "dumb" communications channel, this
question does not seem interesting.  But the related question of "how can
the RS make sure that the access token it got was generated according to
this profile?" does seem interesting, and seems like it would benefit from
the same proposed solution.

> This relates to an email posted by Dominick Baier under the topic "JAR: 
> JWT typ" on May 19 :
> 
>     This has been brought up before - but no response.
> 
>     Either I can’t find it - or it is missing. But is the setting the
>     JWT typ explicitly mentioned somewhere?

It is fairly likely that I will remember to ask about explicit "typ" usage
if I'm still on the IESG when this document gets there: I think I've been
making a habit of doing so.

Thanks,

Ben


From nobody Sat May 30 18:34:28 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F783A1091; Sat, 30 May 2020 18:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ6VdRdsEYWE; Sat, 30 May 2020 18:34:19 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E6A3A1090; Sat, 30 May 2020 18:34:19 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 4528BF40721; Sat, 30 May 2020 18:34:04 -0700 (PDT)
To: resnick@episteme.net, mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200531013404.4528BF40721@rfc-editor.org>
Date: Sat, 30 May 2020 18:34:04 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 01:34:23 -0000

The following errata report has been verified for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Pete Resnick 
Date Reported: 2020-05-26
Verified by: Benjamin Kaduk (IESG)

Section: 7.1

Original Text
-------------
   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7157, May 2015,
              .


Corrected Text
--------------
   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              .


Notes
-----
DOI has a typo: 7157 instead of 7517.

--------------------------------------
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--------------------------------------
Title               : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
Publication Date    : April 2016
Author(s)           : M. Jones, J. Bradley, H. Tschofenig
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Sat May 30 20:55:15 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA33A118C; Sat, 30 May 2020 20:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNJwGDrbdIzY; Sat, 30 May 2020 20:55:08 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD4D3A118A; Sat, 30 May 2020 20:55:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 7C3C7AEDA3D7; Sat, 30 May 2020 22:55:04 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSxSTUFMd9mX; Sat, 30 May 2020 22:55:01 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id CFE62AEDA3CD; Sat, 30 May 2020 22:55:01 -0500 (CDT)
From: "Pete Resnick" 
To: "RFC Errata System" 
Cc: mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net, kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org
Date: Sat, 30 May 2020 22:55:01 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: <20200531013404.4528BF40721@rfc-editor.org>
References: <20200531013404.4528BF40721@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 03:55:10 -0000

"Verified", not "Hold For Document Update"?

pr

On 30 May 2020, at 20:34, RFC Errata System wrote:

> The following errata report has been verified for RFC7800,
> "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6187
>
> --------------------------------------
> Status: Verified
> Type: Editorial
>
> Reported by: Pete Resnick 
> Date Reported: 2020-05-26
> Verified by: Benjamin Kaduk (IESG)
>
> Section: 7.1
>
> Original Text
> -------------
>    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
>               DOI 10.17487/RFC7157, May 2015,
>               .
>
>
> Corrected Text
> --------------
>    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
>               DOI 10.17487/RFC7517, May 2015,
>               .
>
>
> Notes
> -----
> DOI has a typo: 7157 instead of 7517.
>
> --------------------------------------
> RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> --------------------------------------
> Title               : Proof-of-Possession Key Semantics for JSON Web 
> Tokens (JWTs)
> Publication Date    : April 2016
> Author(s)           : M. Jones, J. Bradley, H. Tschofenig
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Sat May 30 21:09:47 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516223A11AA; Sat, 30 May 2020 21:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTi4ym7VWad2; Sat, 30 May 2020 21:09:39 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520DE3A11A9; Sat, 30 May 2020 21:09:39 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04V49O4G023126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 May 2020 00:09:26 -0400
Date: Sat, 30 May 2020 21:09:24 -0700
From: Benjamin Kaduk 
To: Pete Resnick 
Cc: RFC Errata System , mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net, iesg@ietf.org, oauth@ietf.org
Message-ID: <20200531040924.GM58497@kduck.mit.edu>
References: <20200531013404.4528BF40721@rfc-editor.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 04:09:41 -0000

The new text is clearly the right thing, and there is no need
to debate it if/when the document gets updated.  "Don't hold
it; do it now", so to speak -- and noting that (my
understanding/recollection of) the plan for
https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
verified errata, not those in other states, will be displayed.

(Yes, that link 404s at the moment, I assume a caching issue.)

-Ben

On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
> "Verified", not "Hold For Document Update"?
> 
> pr
> 
> On 30 May 2020, at 20:34, RFC Errata System wrote:
> 
> > The following errata report has been verified for RFC7800,
> > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6187
> >
> > --------------------------------------
> > Status: Verified
> > Type: Editorial
> >
> > Reported by: Pete Resnick 
> > Date Reported: 2020-05-26
> > Verified by: Benjamin Kaduk (IESG)
> >
> > Section: 7.1
> >
> > Original Text
> > -------------
> >    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
> >               DOI 10.17487/RFC7157, May 2015,
> >               .
> >
> >
> > Corrected Text
> > --------------
> >    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
> >               DOI 10.17487/RFC7517, May 2015,
> >               .
> >
> >
> > Notes
> > -----
> > DOI has a typo: 7157 instead of 7517.
> >
> > --------------------------------------
> > RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> > --------------------------------------
> > Title               : Proof-of-Possession Key Semantics for JSON Web 
> > Tokens (JWTs)
> > Publication Date    : April 2016
> > Author(s)           : M. Jones, J. Bradley, H. Tschofenig
> > Category            : PROPOSED STANDARD
> > Source              : Web Authorization Protocol
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG
> 
> 
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best


From nobody Sat May 30 21:22:44 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3593A11C4; Sat, 30 May 2020 21:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwQ_v8jsetrP; Sat, 30 May 2020 21:22:35 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FD63A11C1; Sat, 30 May 2020 21:22:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id E0B98AEDB7A8; Sat, 30 May 2020 23:22:34 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKda3xXrQOrE; Sat, 30 May 2020 23:22:34 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 1687DAEDB79C; Sat, 30 May 2020 23:22:34 -0500 (CDT)
From: "Pete Resnick" 
To: "Benjamin Kaduk" 
Cc: "RFC Errata System" , mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net, iesg@ietf.org, oauth@ietf.org
Date: Sat, 30 May 2020 23:22:33 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: <20200531040924.GM58497@kduck.mit.edu>
References: <20200531013404.4528BF40721@rfc-editor.org>  <20200531040924.GM58497@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_848226B9-41D5-44FD-A87E-9956495223BA_="
Archived-At: 
Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 04:22:38 -0000

--=_MailMate_848226B9-41D5-44FD-A87E-9956495223BA_=
Content-Type: text/plain; format=flowed

But 
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
in particular:

1. Only errors that could cause implementation or deployment problems or 
significant confusion should be Verified.
2. Things that are clearly wrong but could not cause an implementation 
or deployment problem should be Hold for Document Update.
5. Typographical errors which would not cause any confusions to 
implementation or deployments should be Hold for Document Update.

Did something change these criteria?

pr

On 30 May 2020, at 23:09, Benjamin Kaduk wrote:

> The new text is clearly the right thing, and there is no need
> to debate it if/when the document gets updated.  "Don't hold
> it; do it now", so to speak -- and noting that (my
> understanding/recollection of) the plan for
> https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
> verified errata, not those in other states, will be displayed.
>
> (Yes, that link 404s at the moment, I assume a caching issue.)
>
> -Ben
>
> On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
>> "Verified", not "Hold For Document Update"?
>>
>> pr
>>
>> On 30 May 2020, at 20:34, RFC Errata System wrote:
>>
>>> The following errata report has been verified for RFC7800,
>>> "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid6187
>>>
>>> --------------------------------------
>>> Status: Verified
>>> Type: Editorial
>>>
>>> Reported by: Pete Resnick 
>>> Date Reported: 2020-05-26
>>> Verified by: Benjamin Kaduk (IESG)
>>>
>>> Section: 7.1
>>>
>>> Original Text
>>> -------------
>>>    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
>>>               DOI 10.17487/RFC7157, May 2015,
>>>               .
>>>
>>>
>>> Corrected Text
>>> --------------
>>>    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
>>>               DOI 10.17487/RFC7517, May 2015,
>>>               .
>>>
>>>
>>> Notes
>>> -----
>>> DOI has a typo: 7157 instead of 7517.
>>>
>>> --------------------------------------
>>> RFC7800 (draft-ietf-oauth-proof-of-possession-11)
>>> --------------------------------------
>>> Title               : Proof-of-Possession Key Semantics for JSON Web
>>> Tokens (JWTs)
>>> Publication Date    : April 2016
>>> Author(s)           : M. Jones, J. Bradley, H. Tschofenig
>>> Category            : PROPOSED STANDARD
>>> Source              : Web Authorization Protocol
>>> Area                : Security
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>
>>
>> -- 
>> Pete Resnick https://www.episteme.net/
>> All connections to the world are tenuous at best


-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_848226B9-41D5-44FD-A87E-9956495223BA_=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable










But https://www.ietf.=
org/about/groups/iesg/statements/processing-rfc-errata/, in particula=
r:



    

  1. Only errors that could cause implementation or deployment=
 problems or significant confusion should be Verified.
    2. 

  2. Things that are clearly wrong but could not cause an impl=
ementation or deployment problem should be Hold for Document Update.
    3. =


  3. Typographical errors which would not cause any confusions=
 to implementation or deployments should be Hold for Document Update.




Did something change these criteria?



pr



On 30 May 2020, at 23:09, Benjamin Kaduk wrote:





T=
he new text is clearly the right thing, and there is no need

to debate it if/when the document gets updated.  "Don't hold

it; do it now", so to speak -- and noting that (my

understanding/recollection of) the plan for

https://www.rfc-editor.org/rfc/inline-errata/rfc7800.ht=
ml is that only

verified errata, not those in other states, will be displayed.



(Yes, that link 404s at the moment, I assume a caching issue.)



-Ben



On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:


"Verified",=
 not "Hold For Document Update"?



pr



On 30 May 2020, at 20:34, RFC Errata System wrote:




The followi=
ng errata report has been verified for RFC7800,

"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".



--------------------------------------

You may review the report below and at:

https://www.rfc-editor.org/errata/eid6187



--------------------------------------

Status: Verified

Type: Editorial



Reported by: Pete Resnick <resnick@episteme.net>

Date Reported: 2020-05-26

Verified by: Benjamin Kaduk (IESG)



Section: 7.1



Original Text

-------------

   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,

              DOI 10.17487/RFC7157, May 2015,

              <http://www.rfc-editor.org/info/rfc7517>.





Corrected Text

--------------

   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,

              DOI 10.17487/RFC7517, May 2015,

              <http://www.rfc-editor.org/info/rfc7517>.





Notes

-----

DOI has a typo: 7157 instead of 7517.



--------------------------------------

RFC7800 (draft-ietf-oauth-proof-of-possession-11)

--------------------------------------

Title               : Proof-of-Possession Key Semantics for JSON Web

Tokens (JWTs)

Publication Date    : April 2016

Author(s)           : M. Jones, J. Bradley, H. Tschofenig

Category            : PROPOSED STANDARD

Source              : Web Authorization Protocol

Area                : Security

Stream              : IETF

Verifying Party     : IESG


-- 

Pete Resnick h=
ttps://www.episteme.net/

All connections to the world are tenuous at best







-- 

Pete Resnick https://www.episteme.net/

All connections to the world are tenuous at best








--=_MailMate_848226B9-41D5-44FD-A87E-9956495223BA_=--


From nobody Sat May 30 21:37:56 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BAF3A11D9 for ; Sat, 30 May 2020 21:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9BQ_DA_oc5m for ; Sat, 30 May 2020 21:37:53 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245B43A11D8 for ; Sat, 30 May 2020 21:37:52 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04V4blXD029242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 May 2020 00:37:49 -0400
Date: Sat, 30 May 2020 21:37:47 -0700
From: Benjamin Kaduk 
To: Denis 
Cc: oauth 
Message-ID: <20200531043747.GN58497@kduck.mit.edu>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 04:37:54 -0000

On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:
> As indicated in the abstract:
> 
>     "This document introduces the ability to send request parameters in
>     a JSON Web Token (JWT) instead,
>       which allows the request to be signed with JSON Web Signature (JWS)".
> 
> This approach has a major consequence which is not indicated in the 
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters such as 
> "please let me make a payment with the amount of 45 Euros"
> or "please give me read access to folder A and write access to file X".
> 
> Such an approach has privacy issues which are currently not documented 
> in the Privacy Considerations section.
> 
> The AS would be in a position to know, not only which resources servers 
> are going to be accessed, but also what kind of operations
> are going to be performed by its clients on the resource servers. With 
> such an approach, ASs will have a deep knowledge of every
> operation that can be performed by a user on every RS.
> 
> As a consequence, the AS would also be in a position to trace the 
> actions performed by its users on the resources servers.
> 
> Other approaches that are more "privacy friendly" should be considered 
> to address the initial problem.

Do you have the start of a list of such other approaches to seed the
discussion?  There seemms to be some inherent tension between the
authorization server knowing what it is authorizing and the privacy
properties you are advocating...

Thanks,

Ben


From nobody Sat May 30 22:24:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3B53A1228 for ; Sat, 30 May 2020 22:24:51 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaJTCeQVICb0 for ; Sat, 30 May 2020 22:24:49 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ADE3A1227 for ; Sat, 30 May 2020 22:24:49 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id q8so3599322iow.7 for ; Sat, 30 May 2020 22:24:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7gbIGsX9FZ5MXz3dclMg+8TNxi4G+7GIzPuna+o5u4Q=; b=iXURmm5/zQqa8o7Q/jtfYoY+/pP38HplUKzB5UC3Yxx4K1DD0BPnRh8uzkLmmhDdJU kO+Gwl4UQ6nlsdWUGDW3lqR4xLexaYtL2F61AgBKz3ChkjlE1L117GBOLbgIeCRa8BwN 0qNLCuI8P9eGpE2//Re8zE/9rm8BvxkifR6odXlinUyMrnDFKysXlP1GyQK0rOydZDKL Wo5qmncbpqeJSvz5LmXb7nFqaQLuKz8TgA8Ii4IEiypGvZrCatB5XFI/Sgm6ojuR2gF2 OtYiFsQPadoJFw28hF3mI+Kf0K8FbsgAOxehuLIizkM4Kz3T8NDfh6WNvb8UaHUlZge1 0kvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7gbIGsX9FZ5MXz3dclMg+8TNxi4G+7GIzPuna+o5u4Q=; b=DbaZtZBgCJ9ehI0wcEcTmv0Yv/V2JTGiM4SHUW9ZySReop/My5zu0Axe2XkQ4xA95l neewzR/WJgnIEXb5g8Sm7CG8f5yRZA+7tsmirxRp82s7pAxEscWJS3/chfG6CxzmT1Ir KrntqiwaJ0EQ9QHDmYlVKUr5XkuuIZHEGE7IJwhMaMXZcYYsrlAMRZDi3QwtG/Mh+8Io dMOSjUmgR3QMBiOQ1+Kqif5e7VGrzN/2yPLm2mssNBYyel/RWBGKz4T/9Bd+MfkqPTZ0 Sz8/i/VbnyaAriiRMBu0t7eUSIGnp7XWhgB+X39uIBD3OMALSgOW/DSQJmtR3aQ8CxB3 HmYA==
X-Gm-Message-State: AOAM531xgyp4MYJnOnsL1FMVO8dcR9HqiEvEn7oDh0bxQ68au0NEqJJj WClFhjJzL5nTj4o0nHmVoEj6vioVzAs=
X-Google-Smtp-Source: ABdhPJz0uPxQd7aHhpqy/tZAh6acD5Q7fQVvYTQ4ySrTTIm4+MM6mx2FT+9nWuADdA9wXbXYnuEWFA==
X-Received: by 2002:a6b:ea10:: with SMTP id m16mr13513674ioc.180.1590902687253;  Sat, 30 May 2020 22:24:47 -0700 (PDT)
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id f10sm7369965ilj.85.2020.05.30.22.24.46 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 May 2020 22:24:46 -0700 (PDT)
Received: by mail-io1-f53.google.com with SMTP id y18so3622597iow.3 for ; Sat, 30 May 2020 22:24:46 -0700 (PDT)
X-Received: by 2002:a02:998b:: with SMTP id a11mr14805591jal.117.1590902686012;  Sat, 30 May 2020 22:24:46 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Sat, 30 May 2020 22:24:35 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Denis 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000078dc4905a6eae564"
Archived-At: 
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 05:24:52 -0000

--00000000000078dc4905a6eae564
Content-Type: text/plain; charset="UTF-8"

> the AS will have the knowledge of these request parameters such as
"please let me make a payment with the amount of 45 Euros"
or "please give me read access to folder A and write access to file X"

Typically in OAuth it's the authorization server's job to inform users and
protect access to their resources. Obviously in order to do that the AS
must know about the details of the request.

Can you please clarify the scenario in which you would want the AS to have
no information about the request that it's authorizing?

Aaron Parecki




On Wed, May 27, 2020 at 10:20 AM Denis  wrote:

> As indicated in the abstract:
>
> "This document introduces the ability to send request parameters in a JSON
> Web Token (JWT) instead,
>   which allows the request to be signed with JSON Web Signature (JWS)".
>
> This approach has a major consequence which is not indicated in the
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters such as "please
> let me make a payment with the amount of 45 Euros"
> or "please give me read access to folder A and write access to file X".
>
> Such an approach has privacy issues which are currently not documented in
> the Privacy Considerations section.
>
> The AS would be in a position to know, not only which resources servers
> are going to be accessed, but also what kind of operations
> are going to be performed by its clients on the resource servers. With
> such an approach, ASs will have a deep knowledge of every
> operation that can be performed by a user on every RS.
>
> As a consequence, the AS would also be in a position to trace the actions
> performed by its users on the resources servers.
>
> Other approaches that are more "privacy friendly" should be considered to
> address the initial problem.
>
> Denis
>
> PS. This email closely relates to the previous email sent on the WG
> mailing list with the following topic:
>        Comments on OAuth 2.0 Rich Authorization Requests
> (draft-ietf-oauth-rar-01)
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com

--00000000000078dc4905a6eae564
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


>=C2=A0the AS will have the knowledge of these request par=
ameters such as "please let me make a payment with the amount of 45 Eu=
ros"
or "please give me=
 read access to folder A and write access to file X"

Typically in OAuth it's the authorizat=
ion server's job to inform users and protect access to their resources.=
 Obviously in order to do that the AS must know about the details of the re=
quest.

Can you please cla=
rify the scenario in which you would want the AS to have no information abo=
ut the request that it's authorizing?

Aaron Parecki




On Wed, May 27, 2020 at 10:20 AM Denis <denis.ietf@free.fr> wrote:

 =20

   =20
 =20
  

    As
        indicated in the abstract: 
    

    

      
=

            "This document introduces the ability to send request
            parameters in a JSON
            Web Token (JWT) instead, 

            =C2=A0 which allows the request to be signed with JSON Web
            Signature (JWS)".

    

    

    
        This approach has a major consequence which is not indicated in
        the
        "Privacy Considerations section: 

        the AS will have the knowledge of these
        request parameters such as "please let me make a payment with
        the amount
        of 45 Euros"

        or "please give me read access to folder A and write
        access to file X".

        

      Such an
        approach has privacy issues which are currently not documented
        in the
        Privacy Considerations section.

        

        The AS would be in a position to know, not only which resources
        servers are
        going to be accessed, but also what kind of operations 

        are going to be
        performed by its clients on the resource servers. With such an
        approach, ASs
        will have a deep knowledge of every 

        operation that can be performed by a user
        on every RS.

        

        As a consequence, the AS would also be in a position to trace
        the actions
        performed by its users on the resources servers. 

      

      Other =
approaches that are more "pri=
vacy friendly" should
      be
      considered to address the initial problem.
    
De=
nis

        

      

    
PS=
. This email closely relates to the previous
        email sent on the WG mailing list with the following topic: 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Comments on OAuth 2.0 Rich Aut=
horization Requests
        (draft-ietf-oauth-rar-01)

      

    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
---
Aaron Par=
ecki



--00000000000078dc4905a6eae564--


From nobody Sat May 30 23:39:26 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4320C3A1295 for ; Sat, 30 May 2020 23:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvjgzrhplmjG for ; Sat, 30 May 2020 23:39:24 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019D13A1294 for ; Sat, 30 May 2020 23:39:24 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 64788F4073C; Sat, 30 May 2020 23:39:08 -0700 (PDT)
To: mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: ericramos1980@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200531063908.64788F4073C@rfc-editor.org>
Date: Sat, 30 May 2020 23:39:08 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC7800 (6195)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 06:39:25 -0000

The following errata report has been submitted for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6195

--------------------------------------
Type: Editorial
Reported by: Eric ramos 

Section: 7157

Original Text
-------------


Corrected Text
--------------
[JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              .


Notes
-----


Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--------------------------------------
Title               : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
Publication Date    : April 2016
Author(s)           : M. Jones, J. Bradley, H. Tschofenig
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Sun May 31 01:22:36 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C413A132F for ; Sun, 31 May 2020 01:22:35 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3cTPqc_PR2I for ; Sun, 31 May 2020 01:22:34 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C433A132E for ; Sun, 31 May 2020 01:22:34 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id j32so5423409qte.10 for ; Sun, 31 May 2020 01:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to; bh=2jRFah6OCbM0qAbZpKMI0GVWiM36suq2cEFfVkYq5pI=; b=ww+P9kZmD3Z2bGFpIk4NprG5fF9+wOfNcgYmGMwkw01JBmwwpXkLBUNm1fNcCAJyzK kbvGx5jyFN4Mwk8d/fhtc4zF7TdI5KAiXfcCkyD/2ZfK2YsXxfDLEtbkxg+IvcYPtujY pD/UZSsoEBpCViFRrguuvA6vNms20tD7zBUiIH9wS0N46O7ich18ukfqeXtG5I5IwFLn TRtV2xVXmcIeQbUI2zEyvMqxYtyxoL90crNCMAlVtb+tGFrpfgxKIwq4mJoDnLY2fzct EFlC0/qjHkQxqcfU4+BeIn8pg+2Eafy0nuhGdz6Pox3mZ1TZN8tfaLF9b4gVgLpp/pvn lnlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=2jRFah6OCbM0qAbZpKMI0GVWiM36suq2cEFfVkYq5pI=; b=R9GNM4pByQq96K/7aCdLrk9AAg/q690SvkX2Ofzbr/RRIm25ChZLHVvJmg5M12hYAT +LSMJT07KBFaMWyG6mUTpzx963z5/QSqeyfy/yiwQVV0Ig+VIVRXIIAo3qbvdm+63h4H QJZlRPcuqxExIFoHcF5ucSJOqli7oUcE2ox1dcaiVJDFhEBUGuhNfKVUs2VzL9Apetpf Yy735B5Y5r4iQrT026fvWAybje6vcSt8dBQULqxUnBtB8DWmxRtmnwKvNlVb7O3wic17 LYKzUSuWdkd7XRzBHv7D3gTbCNFnmPIgV7NS6cXppPnNtfiQde0IrpECi/kI14WeY5OO peag==
X-Gm-Message-State: AOAM533p/8hTOvW6WJj37YKwPJ32xvXuJJcpji0NMdvO7jkk1hha8zxk /QaRwsvZQRYmp/nKO+WvC7rLTuSPGD4LZIyOB65fuw3N6g==
X-Google-Smtp-Source: ABdhPJzbRLDAUYrGQnBqsIQWxn1nY0lGQIXzsisHJctXkZGcS+aWvdRaKXGIAMdriX4NnSK7xSGT9JA68g96nrzGY7E=
X-Received: by 2002:ac8:1942:: with SMTP id g2mr17139824qtk.107.1590913352747;  Sun, 31 May 2020 01:22:32 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 31 May 2020 01:22:31 -0700
From: Dominick Baier 
MIME-Version: 1.0
Date: Sun, 31 May 2020 01:22:31 -0700
Message-ID: 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000042606905a6ed6193"
Archived-At: 
Subject: [OAUTH-WG] To the authors of jwsreq/JAR
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 08:22:36 -0000

--00000000000042606905a6ed6193
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

We had asked a couple of questions over the last weeks regarding details of
the JAR spec. Not a single response from the spec authors.

We are in the process of implementing JAR and about to release the software=
.

We need some clarifications and I am confused that we did not get any
response. Is it a technical issue?

thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

--00000000000042606905a6ed6193
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Hi,=
=C2=A0

<=
/div>
We had asked=
 a couple of questions over the last weeks regarding details of the JAR spe=
c. Not a single response from the spec authors.

We are in the process of implementing JAR and =
about to release the software.

We need some clarifications and I am confused that we did not g=
et any response. Is it a technical issue?

thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier<=
/div>


--00000000000042606905a6ed6193--


From nobody Sun May 31 08:52:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670913A0922 for ; Sun, 31 May 2020 08:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlRGISYHZiyd for ; Sun, 31 May 2020 08:52:14 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8943A0899 for ; Sun, 31 May 2020 08:52:13 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id F0DDD659F; Sun, 31 May 2020 15:52:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1590940331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nrA2JiHyRhW4QxrsDZy0czdYcc8JMVc9SLw/6wFDWxk=; b=RglB4aoR1OGRd9WlIDejEeBjAQXNRJHp28fVa9gFqTjiB0hdRnjH4v1aHzpqU8lJA3WyW6 SjX3TUdKgy5u/4FSqWTutiEr0M1DDdzcFhkzEBj/4qizKDuUEH3/TNla/Rszv06r+ay34U HSbqWVK6gaCP1byzCWTPs6hySdosSbc=
From: Daniel Fett 
To: "oauth@ietf.org" , Openid-specs-fapi , openid-specs-ab@lists.openid.net, HEART OpenID 
Message-ID: 
Date: Sun, 31 May 2020 17:52:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1590940331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nrA2JiHyRhW4QxrsDZy0czdYcc8JMVc9SLw/6wFDWxk=; b=HDjZgjrq9GQBw8+FpVdexTSzsAGBM+N8g3aBnX0vBLNeGLZJJbqLR43eXU0POzgt2usjAK 5EBYCD9RsYyM0QVuzfY6Jx5iCdpwlabHOhGG+mgeHpktbdJxwbv6SHgEC4qVIbMhtBqidl si/Ehtlt0atJJIuMXJK/8HHotyd8eMY=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1590940331; a=rsa-sha256; cv=none; b=VoYQDJ2HB/Q9hT1X9q8A7dqQcXTsdzbQOsik//MpgAdSQcfo+fDZ3B8MR9+L0IPhzv5HRk m/jJ5ChKPky6zso8YXpV3tw/Q6AnsCX/alQakHBZ4qCFA2BkZU/degxvQmqyA0pJb5z/DE DioTIVUy6/i8uo9ukguA18Qk39Lpl3E=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: +
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Archived-At: 
Subject: [OAUTH-WG] Virtual OAuth Security Workshop 2020, July 21-24
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 15:52:15 -0000

Website: https://osw2020.com/
Registration: https://barcamptools.eu/oauth-security-workshop-2020/
Twitter: https://twitter.com/secworkshop

The OAuth Security Workshop 2020 will be held as a virtual event on July
21 to 24. As Zoom Fatigue is a real thing, the workshop will be spread
over four days (compared to the originally planned three days).

As in 2019, the OSW will be a mix of pre-scheduled tutorials and talks,
and an unconference part where every participant can propose and conduct
a session. Sessions in the unconference are often driven by recent
discussions in the community, but can also be used to deep-dive into
topics from the talks and tutorials, or to discuss or work on any
OAuth-related topic.

The event will be free of charge. A prior registration is required:
https://barcamptools.eu/oauth-security-workshop-2020/

Schedule outline:

July 21 (Tutorials/Workshops day): On the first day, we will have two
tutorial slots with up to 3 hours each. If needed, multiple tutorials
can run in parallel.

July 22 (Talks day): The second day starts with the official opening of
the workshop, followed by two parallel tracks of talks with eight talk
slots each. Each talk is 25 minutes.

July 23 and July 24 (Unconference days): At the beginning of each of the
two days, sessions are proposed and scheduled in the plenum. Sessions
can be anything from talks to open discussions or tutorials. We will
have up to three parallel session tracks with five slots each (four plus
closing on the last day), 45 minutes each.

The precise times in various time zones can be found on the website:
https://osw2020.com/

The full schedule for talks and workshops will be published in June.

Session proposals for the unconference part can be submitted ahead of
time on the registration website.


If you have any questions, feel free to contact me (mail@danielfett.de).

-Daniel


From nobody Sun May 31 09:12:41 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C43A08A5 for ; Sun, 31 May 2020 09:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJu-Uyj-L2DB for ; Sun, 31 May 2020 09:12:38 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E413A089C for ; Sun, 31 May 2020 09:12:38 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 70DE364C9 for ; Sun, 31 May 2020 16:12:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1590941554; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0pg9wp5zZOcLbxmGI1Aju+k8lXCKo+OrriAeWVNuW90=; b=p82B5WNjxozJy5LVq5BZCXu+Ue/VLX6Be17EFTYykOZ1VNKolXP8gWKXpa1V9AHWdehUgC O0BNWlGCWt+KDUukNo5tmOIc8/Od2bJ5e9VC0UEqVtffdQGrU74J98S247dFP2WXfJwFWr G4ntQKdFZYxXnAL37NtjqpvxDUd3Rbg=
From: Daniel Fett 
To: "oauth@ietf.org" 
References: 
Message-ID: <8676c234-3728-1fe0-f923-23a09ad9eff3@danielfett.de>
Date: Sun, 31 May 2020 18:12:33 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1BF0E45514DE469B29F9B68F"
Content-Language: en-US
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1590941555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0pg9wp5zZOcLbxmGI1Aju+k8lXCKo+OrriAeWVNuW90=; b=qQPbYMbWoZHS5pfR/dcU9DwoM4/o2OUa+JJxYySIxYOmiWpcvcBAsK02Dmw2TIJf3KEXdm exdkcTYWmc5FfYu0SsKP8cNprhugox53+Cc3cXVXdxkdrorApKM4lKi9dofy3QnyG0UWdN s2DyYwarBm1fF57oK4dB96C4wQfq44o=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1590941555; a=rsa-sha256; cv=none; b=QT1FwOLWd09Jf3Na0n80qy3Lo7lLwp/yNn8lAX30eGpMe2EH+PlIZdFxfIs59zY8PvPrTV rBOGjTHaS+FMOF2l3H5gReMbZOgvcqFyv5WX3QsVw2G9AH60R66AulO2us+cuVp2bgE4C9 faFYZ7c/KP/9+QjvwjOSq9e0Z3Nj+5w=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: ++
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Archived-At: 
Subject: Re: [OAUTH-WG] Virtual OAuth Security Workshop 2020, July 21-24
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 16:12:40 -0000

This is a multi-part message in MIME format.
--------------1BF0E45514DE469B29F9B68F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi all,

I hope that many of you can make it to the virtual OSW!

While the official call is closed, we can easily fit some more
tutorials/workshops or talks into the schedule. If you are interested to
host a session, please contact me.

Finding good start and end times for an event with participants from all
over the world is not easy. To find out which time zones we need to
accommodate for and when people in these time zones are usually working,
I took the mails from this mailing list as a guide line. I used a python
script to scrape and analyze the mails from the past 17 months. If you
are interested in the results, please see this sheet:
https://docs.google.com/spreadsheets/d/1idVpjHdbbYfDEflUc8RXwfNoYWZWvITk7SMjh3T699o/edit?usp=sharing

In the end, the schedule ended up very close to the one of IETF 108,
which hopefully works for many attendees.

-Daniel



Am 31.05.20 um 17:52 schrieb Daniel Fett:
> Website: https://osw2020.com/
> Registration: https://barcamptools.eu/oauth-security-workshop-2020/
> Twitter: https://twitter.com/secworkshop
>
> The OAuth Security Workshop 2020 will be held as a virtual event on July
> 21 to 24. As Zoom Fatigue is a real thing, the workshop will be spread
> over four days (compared to the originally planned three days).
>
> As in 2019, the OSW will be a mix of pre-scheduled tutorials and talks,
> and an unconference part where every participant can propose and conduct
> a session. Sessions in the unconference are often driven by recent
> discussions in the community, but can also be used to deep-dive into
> topics from the talks and tutorials, or to discuss or work on any
> OAuth-related topic.
>
> The event will be free of charge. A prior registration is required:
> https://barcamptools.eu/oauth-security-workshop-2020/
>
> Schedule outline:
>
> July 21 (Tutorials/Workshops day): On the first day, we will have two
> tutorial slots with up to 3 hours each. If needed, multiple tutorials
> can run in parallel.
>
> July 22 (Talks day): The second day starts with the official opening of
> the workshop, followed by two parallel tracks of talks with eight talk
> slots each. Each talk is 25 minutes.
>
> July 23 and July 24 (Unconference days): At the beginning of each of the
> two days, sessions are proposed and scheduled in the plenum. Sessions
> can be anything from talks to open discussions or tutorials. We will
> have up to three parallel session tracks with five slots each (four plus
> closing on the last day), 45 minutes each.
>
> The precise times in various time zones can be found on the website:
> https://osw2020.com/
>
> The full schedule for talks and workshops will be published in June.
>
> Session proposals for the unconference part can be submitted ahead of
> time on the registration website.
>
>
> If you have any questions, feel free to contact me (mail@danielfett.de).
>
> -Daniel
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------1BF0E45514DE469B29F9B68F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi all,

    


    

    
I hope that many of you can make it to
      the virtual OSW! 

    

    


    

    
While the official call is closed, we
      can easily fit some more tutorials/workshops or talks into the
      schedule. If you are interested to host a session, please contact
      me.

    


    

    
Finding good start and end times for an
      event with participants from all over the world is not easy. To
      find out which time zones we need to accommodate for and when
      people in these time zones are usually working, I took the mails
      from this mailing list as a guide line. I used a python script to
      scrape and analyze the mails from the past 17 months. If you are
      interested in the results, please see this sheet:
https://docs.google.com/spreadsheets/d/1idVpjHdbbYfDEflUc8RXwfNoYWZWvITk7SMjh3T699o/edit?usp=sharing

    


    

    
 In the end, the schedule ended up very
      close to the one of IETF 108, which hopefully works for many
      attendees.

    

    


    

    
-Daniel

    

    

    


    

    


    

    
Am 31.05.20 um 17:52 schrieb Daniel
      Fett:

    

    

      
Website: https://osw2020.com/
Registration: https://barcamptools.eu/oauth-security-workshop-2020/
Twitter: https://twitter.com/secworkshop

The OAuth Security Workshop 2020 will be held as a virtual event on July
21 to 24. As Zoom Fatigue is a real thing, the workshop will be spread
over four days (compared to the originally planned three days).

As in 2019, the OSW will be a mix of pre-scheduled tutorials and talks,
and an unconference part where every participant can propose and conduct
a session. Sessions in the unconference are often driven by recent
discussions in the community, but can also be used to deep-dive into
topics from the talks and tutorials, or to discuss or work on any
OAuth-related topic.

The event will be free of charge. A prior registration is required:
https://barcamptools.eu/oauth-security-workshop-2020/

Schedule outline:

July 21 (Tutorials/Workshops day): On the first day, we will have two
tutorial slots with up to 3 hours each. If needed, multiple tutorials
can run in parallel.

July 22 (Talks day): The second day starts with the official opening of
the workshop, followed by two parallel tracks of talks with eight talk
slots each. Each talk is 25 minutes.

July 23 and July 24 (Unconference days): At the beginning of each of the
two days, sessions are proposed and scheduled in the plenum. Sessions
can be anything from talks to open discussions or tutorials. We will
have up to three parallel session tracks with five slots each (four plus
closing on the last day), 45 minutes each.

The precise times in various time zones can be found on the website:
https://osw2020.com/

The full schedule for talks and workshops will be published in June.

Session proposals for the unconference part can be submitted ahead of
time on the registration website.


If you have any questions, feel free to contact me (mail@danielfett.de).

-Daniel

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


    

    


    

  


--------------1BF0E45514DE469B29F9B68F--


From nobody Sun May 31 10:47:22 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB94D3A0AC8; Sun, 31 May 2020 10:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAGkapjR0shg; Sun, 31 May 2020 10:47:14 -0700 (PDT)
Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F42F3A0AC7; Sun, 31 May 2020 10:47:14 -0700 (PDT)
Received: by mail-il1-f179.google.com with SMTP id r2so7252186ila.4; Sun, 31 May 2020 10:47:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4uSQNfSp//dDeRXqUZVZa5vl59cW3lUFIWM6gKIV+EA=; b=XQDR6VeYqkJ3ZzZ4yDD04WTbRoS3/OeLjA8SG3YJewU1LW0ctvmcMfKwEa8kprTb6q D9eTAtpmEAMTd9rum/OVSxwCFSOempVafT9HOLq40tkh9OuDoE8i6hlPitJ2Z8yoBCwP 25hooKRbJoNwuFLtF3bRTirFgOCpzbsFl6ca5cdYHVZG4xDG7EDFjkY+Z7rZ1st11s8F z7ZLcwQBLu0FxyLFRFehF8d/xntuVrD5p5WC05+lGzAIEmJw8flhbKJ95+urFdlgOitl wl63490wxMcDKdA468UgXXPlXcwNsEjO6uuvNCMuj9aGmSeLF8pIVAi0iFzZcEQ5eeEr T6Cg==
X-Gm-Message-State: AOAM533EZTLTBsdMz9wgXh66sghYNVp8Mz4M50nsLDBkXADGItDNqlwY +hOClyUlmNiE3sAsSX12ZHmJh74sxFfgZYRdyNk=
X-Google-Smtp-Source: ABdhPJzT0TdbuPmfGBdlYvrqtLn2WWJr+MweuqH0BWt4I3yY1zfwtCb3K4bZUTk5Cnj9M6DkEpE+vKPrfezkvdhUimU=
X-Received: by 2002:a05:6e02:10c:: with SMTP id t12mr2622567ilm.187.1590947233643;  Sun, 31 May 2020 10:47:13 -0700 (PDT)
MIME-Version: 1.0
References: <20200531013404.4528BF40721@rfc-editor.org>  <20200531040924.GM58497@kduck.mit.edu> 
In-Reply-To: 
From: Barry Leiba 
Date: Sun, 31 May 2020 13:47:02 -0400
Message-ID: 
To: Pete Resnick 
Cc: Benjamin Kaduk , Michael Jones , IESG ,  John Bradley , Hannes Tschofenig , oauth WG , RFC Errata System 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 17:47:16 -0000

> But https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, in particular:
>
> Only errors that could cause implementation or deployment problems or significant confusion should be Verified.
> Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update.
> Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update.
>
> Did something change these criteria?

They're guidelines, not absolute rules, and judgment is expected.  I
support the guidelines, but I also appreciate and support Ben's good
judgment.  I, at least, am happy to leave it at that.

(That said, I did mark John Levine's errata report against RFC 20 as HFDU....)

Barry


From nobody Sun May 31 10:59:09 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1160B3A0AE3; Sun, 31 May 2020 10:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhsKGO_FBoaM; Sun, 31 May 2020 10:59:01 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE07C3A0AE1; Sun, 31 May 2020 10:59:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id C1E11AEEEAC6; Sun, 31 May 2020 12:58:57 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZhfhoqlcFhD; Sun, 31 May 2020 12:58:54 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 98AF1AEEEA81; Sun, 31 May 2020 12:58:54 -0500 (CDT)
From: "Pete Resnick" 
To: "Barry Leiba" 
Cc: "Benjamin Kaduk" , "Michael Jones" , IESG , "John Bradley" , "Hannes Tschofenig" , "oauth WG" ,  "RFC Errata System" 
Date: Sun, 31 May 2020 12:58:54 -0500
X-Mailer: MailMate (1.13.1r5683)
Message-ID: 
In-Reply-To: 
References: <20200531013404.4528BF40721@rfc-editor.org>  <20200531040924.GM58497@kduck.mit.edu>  
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; markup=markdown
Archived-At: 
Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 17:59:03 -0000

On 31 May 2020, at 12:47, Barry Leiba wrote:

>> But 
>> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
>> in particular:
>>
>> Only errors that could cause implementation or deployment problems or 
>> significant confusion should be Verified.
>> Things that are clearly wrong but could not cause an implementation 
>> or deployment problem should be Hold for Document Update.
>> Typographical errors which would not cause any confusions to 
>> implementation or deployments should be Hold for Document Update.
>>
>> Did something change these criteria?
>
> They're guidelines, not absolute rules, and judgment is expected.

Sure, but I was replying to Ben's statement that, "The new text is 
clearly the right thing, and there is no need to debate it if/when the 
document gets updated.  'Don't hold it; do it now', so to speak". That's 
not what Verified ever meant before. If the meaning has changed, that's 
fine, but someone should let the community know and update the IESG 
Statement. (Personally, I'm all for that, as I've found the current 
definitions absurd and confusing. All clearly wrong Editorial errata 
should be marked "Verified", IMO.) But that's not about applying 
judgement; that's changing the definition of the terms used.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best


From nobody Sun May 31 12:41:42 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0E3A00B0 for ; Sun, 31 May 2020 12:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di0AcYcA-PCH for ; Sun, 31 May 2020 12:41:39 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250D43A0045 for ; Sun, 31 May 2020 12:41:39 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id x14so9430976wrp.2 for ; Sun, 31 May 2020 12:41:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UtoMdoEedOoF9L3KeW7ca2PfVgWkL6+BOHVuTLlM40c=; b=ur6bq9sGD/qxslHCtsPsNawDCffWmwq7MKbWa7dmg170fHbPjdmaz+V7oBdEdKZVDO 1rftohxvX2gsPiHlZ+KaAwADCJHRAF4dpQREmn+75SZOglVNr1ZH5EwjvuG0xMqOtBGo ON+j1vY28/5uqYD7XLWbrVX1iCypHpRLTLGxS35X6olvkEVY4dnX/wjmRsJPEBpbtdV3 Km9V+te0NMspM32zExGNKox3e4mCzFKMSAT/Sz4kc310GQLGMAwTFSXS0Agou9owU5WG wZbuHnFTEHbugc+alKW7wMpd8+P7wAl1hA+pjgTVXbP/1e+kfVG3mlG8GcrInHP0nW6I 34pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UtoMdoEedOoF9L3KeW7ca2PfVgWkL6+BOHVuTLlM40c=; b=nRIal5ngo4UhPJI/UTGjgBdcYTo46O+0XT/xACGUYK4Led6KcslHy+EMGK++WtHECH 6MMgsRkdnV33QO1GzeCiIbC+Xpf5DohYYczLfo8zUKoHHng7BWapMlZKM5h4rPjv3r57 RWiufBBuiSCrHvJZqOPD/OezoMEIs1nq9RsWVmyQu2KxkpTe7/DpMGNLBKHfbVaRzd46 2ZMxspoIbtnuyNF0l4/vjxx9UpdkUAJkkY7JaGpODRkPshFGOPqvuH84z+d6VwwNYHEK 0uDedN2mAocsxpxvOoHsDPb3aAR1vr/tQ7Aa1CWswTp+Ioq0TWC9SekzRakEPZ5GpXMK x2IQ==
X-Gm-Message-State: AOAM5315Xy6UBGFIZFi3q4ltAGyY2z9NhEUTCY2aOQYaibaExSUHA5fi HKrA1JHyobq2uYR0QG/PP+5dJOY5KMCF6RFR01w=
X-Google-Smtp-Source: ABdhPJwAsVBFPAKkF+LEaa3DJn9mV2hkOd6g9hVV6uPYIQT/xuXFGETpCrK3kzTgvOocPCgN1ZVEL1f3TVqSEiH/RZ0=
X-Received: by 2002:adf:82d0:: with SMTP id 74mr17516643wrc.138.1590954067671;  Sun, 31 May 2020 12:41:07 -0700 (PDT)
MIME-Version: 1.0
References: <20200518100426.ACC2DF40753@rfc-editor.org> <20200523202532.GE58497@kduck.mit.edu>
In-Reply-To: <20200523202532.GE58497@kduck.mit.edu>
From: Rifaat Shekh-Yusef 
Date: Sun, 31 May 2020 15:40:56 -0400
Message-ID: 
To: Benjamin Kaduk 
Cc: RFC Errata System , n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com,  naa@google.com, rdd@cert.org, Hannes Tschofenig ,  dmitry.khlebnikov@rea-group.com, oauth 
Content-Type: multipart/alternative; boundary="0000000000000ebd8c05a6f6dc80"
Archived-At: 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 19:41:41 -0000

--0000000000000ebd8c05a6f6dc80
Content-Type: text/plain; charset="UTF-8"

Nat, John,

Do you guys have any thoughts on this errata?

Regards,
 Rifaat


On Sat, May 23, 2020 at 4:25 PM Benjamin Kaduk  wrote:

> Authors, WG, any comments?
>
> Right now the likely dispositions seem to me to be Editorial/HFDU or
> Rejected; the text is noting that salting is not used and attempting to
> give an explanation of why that's the right choice.  It's not clear that
> the WG was in error to include some such discussion at the time of
> publication, which is essentially what this errata report is claiming.
>
> Thanks,
>
> Ben
>
> On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7636,
> > "Proof Key for Code Exchange by OAuth Public Clients".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6179
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Dmitry Khlebnikov 
> >
> > Section: 7.3
> >
> > Original Text
> > -------------
> > 7.3.  Salting the code_challenge
> >
> >    To reduce implementation complexity, salting is not used in the
> >    production of the code challenge, as the code verifier contains
> >    sufficient entropy to prevent brute-force attacks.  Concatenating a
> >    publicly known value to a code verifier (containing 256 bits of
> >    entropy) and then hashing it with SHA256 to produce a code challenge
> >    would not increase the number of attempts necessary to brute force a
> >    valid value for code verifier.
> >
> >    While the "S256" transformation is like hashing a password, there are
> >    important differences.  Passwords tend to be relatively low-entropy
> >    words that can be hashed offline and the hash looked up in a
> >    dictionary.  By concatenating a unique though public value to each
> >    password prior to hashing, the dictionary space that an attacker
> >    needs to search is greatly expanded.
> >
> >    Modern graphics processors now allow attackers to calculate hashes in
> >    real time faster than they could be looked up from a disk.  This
> >    eliminates the value of the salt in increasing the complexity of a
> >    brute-force attack for even low-entropy passwords.
> >
> > Corrected Text
> > --------------
> >
> >
> > Notes
> > -----
> > The section misrepresents the information about "salting" and the whole
> idea
> > of "salting" is not applicable to a standalone hash.  I suggest to drop
> the entire
> > section as irrelevant to the rest of the standard.
> >
> > For some reason the section implies that "salting" is protecting and
> increasing
> > entropy of a single hash, which is not what "salting" is about and is
> not the
> > reason for the technique.  The section is also making a speculative
> assumptions
> > about the low-entropy tendency in password hashes and makes an incorrect
> > conclusion on the benefits of "salting" for a password hash.
> >
> > One could argue that the entropy and the complexity required to
> bruteforce a hash
> > and a salted hash for the same password (where the same hashing
> algorithm is
> > applied) are approximately the same in most cases (or just slightly more
> > complex for the salted version if the producer of the hash used a
> non-standard
> > routine in relation of mixing in the salt, e.g. instead of appending the
> salt
> > it inserts in in the middle of the password to be hashed).  In any case,
> that
> > public data is already known to the attacker and it is just a matter of
> the
> > configuration for the bruteforcing tool (such as JohnTheRipper) to
> incorporate
> > the knowledge.
> >
> > Just as an illustration: consider an example password ('abc'), an
> example salt
> > ('123'), and that the hash is generated using a concatinated version of
> these
> > two (e.g. HASH('abc123')).  Since the salt is included with the hash in
> plain
> > text, the bruteforcer would just need to set their tool up with the
> "^.*123$"
> > pattern making the salt essentially a string terminator which is not
> affecting
> > the bruteforce effort in any way).
> >
> > More and more people I meet are confused about the problem area the
> "salting"
> > technique was invented to address: it is to increase the entropy of a
> set of
> > passwords, so the same password would not result in the same hash value,
> with
> > the primary goal is to prevent attackers to be able to re-use
> pre-calculated
> > hashes (e.g. rainbow hash tables) or, in the early stages of the attack,
> to
> > make it impossible to quickly assess what hashes the attacker should
> focus on
> > (e.g.  when you have 1000 hashes and without salts you can easily spot
> that
> > some hashes are the same, which means breaking these one would gain much
> more
> > in comparison to unique hashes in the same set).
> >
> > This being said, I am suggesting to drop section 7.3 completely as
> irrelevant,
> > since what we currently have is very confusing and seeds unnecessary and
> > wrong ideas that "salting" can improve the security of a single hash by
> itself.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC7636 (draft-ietf-oauth-spop-15)
> > --------------------------------------
> > Title               : Proof Key for Code Exchange by OAuth Public Clients
> > Publication Date    : September 2015
> > Author(s)           : N. Sakimura, Ed., J. Bradley, N. Agarwal
> > Category            : PROPOSED STANDARD
> > Source              : Web Authorization Protocol
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG
>

--0000000000000ebd8c05a6f6dc80
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Nat, John,

Do you guys have any thought=
s on=C2=A0this errata?

Regards,
=C2=A0Ri=
faat


On Sat, May 23, 2020 at 4:25 PM Benjamin Kaduk <=
;kaduk@mit.edu> wrote:
Authors, WG, any comments?


Right now the likely dispositions seem to me to be Editorial/HFDU or

Rejected; the text is noting that salting is not used and attempting to

give an explanation of why that's the right choice.=C2=A0 It's not =
clear that

the WG was in error to include some such discussion at the time of

publication, which is essentially what this errata report is claiming.



Thanks,



Ben



On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote:

> The following errata report has been submitted for RFC7636,

> "Proof Key for Code Exchange by OAuth Public Clients".

> 

> --------------------------------------

> You may review the report below and at:

> https://www.rfc-editor.org/errata/eid6179

> 

> --------------------------------------

> Type: Technical

> Reported by: Dmitry Khlebnikov <dmitry.khlebnikov@rea-group.com>
> 

> Section: 7.3

> 

> Original Text

> -------------

> 7.3.=C2=A0 Salting the code_challenge

> 

>=C2=A0 =C2=A0 To reduce implementation complexity, salting is not used =
in the

>=C2=A0 =C2=A0 production of the code challenge, as the code verifier co=
ntains

>=C2=A0 =C2=A0 sufficient entropy to prevent brute-force attacks.=C2=A0 =
Concatenating a

>=C2=A0 =C2=A0 publicly known value to a code verifier (containing 256 b=
its of

>=C2=A0 =C2=A0 entropy) and then hashing it with SHA256 to produce a cod=
e challenge

>=C2=A0 =C2=A0 would not increase the number of attempts necessary to br=
ute force a

>=C2=A0 =C2=A0 valid value for code verifier.

> 

>=C2=A0 =C2=A0 While the "S256" transformation is like hashing=
 a password, there are

>=C2=A0 =C2=A0 important differences.=C2=A0 Passwords tend to be relativ=
ely low-entropy

>=C2=A0 =C2=A0 words that can be hashed offline and the hash looked up i=
n a

>=C2=A0 =C2=A0 dictionary.=C2=A0 By concatenating a unique though public=
 value to each

>=C2=A0 =C2=A0 password prior to hashing, the dictionary space that an a=
ttacker

>=C2=A0 =C2=A0 needs to search is greatly expanded.

> 

>=C2=A0 =C2=A0 Modern graphics processors now allow attackers to calcula=
te hashes in

>=C2=A0 =C2=A0 real time faster than they could be looked up from a disk=
.=C2=A0 This

>=C2=A0 =C2=A0 eliminates the value of the salt in increasing the comple=
xity of a

>=C2=A0 =C2=A0 brute-force attack for even low-entropy passwords.

> 

> Corrected Text

> --------------

> 

> 

> Notes

> -----

> The section misrepresents the information about "salting" an=
d the whole idea 

> of "salting" is not applicable to a standalone hash.=C2=A0 I=
 suggest to drop the entire

> section as irrelevant to the rest of the standard.

> 

> For some reason the section implies that "salting" is protec=
ting and increasing

> entropy of a single hash, which is not what "salting" is abo=
ut and is not the

> reason for the technique.=C2=A0 The section is also making a speculati=
ve assumptions

> about the low-entropy tendency in password hashes and makes an incorre=
ct

> conclusion on the benefits of "salting" for a password hash.=


> 

> One could argue that the entropy and the complexity required to brutef=
orce a hash

> and a salted hash for the same password (where the same hashing algori=
thm is

> applied) are approximately the same in most cases (or just slightly mo=
re

> complex for the salted version if the producer of the hash used a non-=
standard

> routine in relation of mixing in the salt, e.g. instead of appending t=
he salt

> it inserts in in the middle of the password to be hashed).=C2=A0 In an=
y case, that

> public data is already known to the attacker and it is just a matter o=
f the

> configuration for the bruteforcing tool (such as JohnTheRipper) to inc=
orporate

> the knowledge.

> 

> Just as an illustration: consider an example password ('abc'),=
 an example salt

> ('123'), and that the hash is generated using a concatinated v=
ersion of these

> two (e.g. HASH('abc123')).=C2=A0 Since the salt is included wi=
th the hash in plain

> text, the bruteforcer would just need to set their tool up with the &q=
uot;^.*123$"

> pattern making the salt essentially a string terminator which is not a=
ffecting

> the bruteforce effort in any way).

> 

> More and more people I meet are confused about the problem area the &q=
uot;salting"

> technique was invented to address: it is to increase the entropy of a =
set of

> passwords, so the same password would not result in the same hash valu=
e, with

> the primary goal is to prevent attackers to be able to re-use pre-calc=
ulated

> hashes (e.g. rainbow hash tables) or, in the early stages of the attac=
k, to

> make it impossible to quickly assess what hashes the attacker should f=
ocus on

> (e.g.=C2=A0 when you have 1000 hashes and without salts you can easily=
 spot that

> some hashes are the same, which means breaking these one would gain mu=
ch more

> in comparison to unique hashes in the same set).

> 

> This being said, I am suggesting to drop section 7.3 completely as irr=
elevant, 

> since what we currently have is very confusing and seeds unnecessary a=
nd

> wrong ideas that "salting" can improve the security of a sin=
gle hash by itself.

> 

> Instructions:

> -------------

> This erratum is currently posted as "Reported". If necessary=
, please

> use "Reply All" to discuss whether it should be verified or<=
br>
> rejected. When a decision is reached, the verifying party=C2=A0 

> can log in to change the status and edit the report, if necessary. 
> 

> --------------------------------------

> RFC7636 (draft-ietf-oauth-spop-15)

> --------------------------------------

> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Proof Ke=
y for Code Exchange by OAuth Public Clients

> Publication Date=C2=A0 =C2=A0 : September 2015

> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: N. Sakimura, Ed., =
J. Bradley, N. Agarwal

> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<=
br>
> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Web Authoriza=
tion Protocol

> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=


> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF

> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG




--0000000000000ebd8c05a6f6dc80--


From nobody Sun May 31 15:27:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DAF3A00AD; Sun, 31 May 2020 15:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEA7XhOn0MDd; Sun, 31 May 2020 15:27:52 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B263A0064; Sun, 31 May 2020 15:27:51 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04VMRg3a016859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 May 2020 18:27:44 -0400
Date: Sun, 31 May 2020 15:27:42 -0700
From: Benjamin Kaduk 
To: Pete Resnick 
Cc: Barry Leiba , Michael Jones ,  IESG , John Bradley , Hannes Tschofenig , oauth WG , RFC Errata System 
Message-ID: <20200531222742.GB58497@kduck.mit.edu>
References: <20200531013404.4528BF40721@rfc-editor.org>  <20200531040924.GM58497@kduck.mit.edu>   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 22:27:54 -0000

On Sun, May 31, 2020 at 12:58:54PM -0500, Pete Resnick wrote:
> On 31 May 2020, at 12:47, Barry Leiba wrote:
> 
> >> But 
> >> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
> >> in particular:
> >>
> >> Only errors that could cause implementation or deployment problems or 
> >> significant confusion should be Verified.
> >> Things that are clearly wrong but could not cause an implementation 
> >> or deployment problem should be Hold for Document Update.
> >> Typographical errors which would not cause any confusions to 
> >> implementation or deployments should be Hold for Document Update.
> >>
> >> Did something change these criteria?
> >
> > They're guidelines, not absolute rules, and judgment is expected.
> 
> Sure, but I was replying to Ben's statement that, "The new text is 
> clearly the right thing, and there is no need to debate it if/when the 
> document gets updated.  'Don't hold it; do it now', so to speak". That's 

To be clear, that was an off-the-cuff remark and not a considered opinion.

> not what Verified ever meant before. If the meaning has changed, that's 
> fine, but someone should let the community know and update the IESG 
> Statement. (Personally, I'm all for that, as I've found the current 
> definitions absurd and confusing. All clearly wrong Editorial errata 

They're also not especially internally consistent.  The first point quoted
lists causing "significant confusion" as grounds for Verified, but the
second point doesn't, even though it lists the other two items and one
might expect it to mirror the first point.

Would having a link to go a completely different document than one should
be seeing cause "significant confusion"?  For some people, I think it
would.  I've certainly had such cases, myself, before -- IIRC I put a
Discuss on a document that referenced RFC 7519 when it meant 7159 (in that
case, the "wrong" document was close-enough to topical to be plausible,
albeit incorrect).

-Ben

> should be marked "Verified", IMO.) But that's not about applying 
> judgement; that's changing the definition of the terms used.
> 
> pr
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best


From nobody Sun May 31 15:39:32 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592263A060A; Sun, 31 May 2020 15:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7_54fZGdeFL; Sun, 31 May 2020 15:39:24 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711703A0602; Sun, 31 May 2020 15:39:24 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5A9C9F406F6; Sun, 31 May 2020 15:39:08 -0700 (PDT)
To: ericramos1980@gmail.com, mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200531223908.5A9C9F406F6@rfc-editor.org>
Date: Sun, 31 May 2020 15:39:08 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Errata Rejected] RFC7800 (6195)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 22:39:25 -0000

The following errata report has been rejected for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6195

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Eric ramos 
Date Reported: 2020-05-31
Rejected by: Benjamin Kaduk (IESG)

Section: 7157

Original Text
-------------


Corrected Text
--------------
[JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              .


Notes
-----

 --VERIFIER NOTES-- 
   Seems to be a (malformed?) duplicate of eid 6187

--------------------------------------
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--------------------------------------
Title               : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
Publication Date    : April 2016
Author(s)           : M. Jones, J. Bradley, H. Tschofenig
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Sun May 31 17:03:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A323A086C for ; Sun, 31 May 2020 17:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5pXhDzpZ_cj for ; Sun, 31 May 2020 17:03:46 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A283A086B for ; Sun, 31 May 2020 17:03:46 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id g14so2769950uaq.0 for ; Sun, 31 May 2020 17:03:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qRYwmjCsikH9nYMdJjRcjNJ16V215ujobhfHyW+K/Z8=; b=CgCji0iWCNHOH4eZo95H8lMuMTQjcIC2R/9PQ6abHm13F8+Eur1n4YOOWliVtORTb+ wUj7HMzYxK3b94Xqcx5l271NTQt5daAHzy68ZBSm48rxBHAgqieHPla8MAxDAy3symDA gcJrn18boxtC4GXtcVFqrhIXXu90g05S75Bqo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qRYwmjCsikH9nYMdJjRcjNJ16V215ujobhfHyW+K/Z8=; b=VdidNUr1UQIrZu8sIvGG2lz8NmWN0Qh62ipRYUIYRRt3t5HfUN5UtW5TD3hWLsGaqH gdjRxWFdZmd8eY1lxZg8zJJkSvvBg8UROjSzvQhQTh+fBFUmaXbcUZ7DzW27abIq3wMw R6BHyP9/MJwUdJdrYqm1MizrVCAzlKWt7n4flYHkVV1QfYkoxfG7FLPMRwEH6rFF3zIJ Wb2CCjnLgWaIButJrE9zH0ZjFsoslUXCIjmxt3ir4wfJZ0kylQyYbhucRkIzV/OCTeHX vchUqHBwzqK3x1CrEql7eqrs1xD7/FwzqJRvxndztD2/sqXBqVkLFOfE7E3hGWokkmMq i+8g==
X-Gm-Message-State: AOAM533UlT9N06+DMiLJq8HF2iFvqdVVpsljEJ9vA+yZmf4nA4TCoO7d H/5o2ZF6H1/T26RC2f1XFfPTzK7dE3RsVqE9wfMWf2c6
X-Google-Smtp-Source: ABdhPJzXCjrANyVWBBLTTXqAwJAI6uWfUvhzuXsCFE/9wzPPW34vvBNADS2A5vyR2DCNDOEYRkLbnOMQru8mCz/a/aY=
X-Received: by 2002:ab0:7202:: with SMTP id u2mr11788124uao.119.1590969824001;  Sun, 31 May 2020 17:03:44 -0700 (PDT)
MIME-Version: 1.0
References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
In-Reply-To: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
From: Ryan Kelly 
Date: Mon, 1 Jun 2020 10:03:33 +1000
Message-ID: 
To: Daniel Fett 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000035615905a6fa871e"
Archived-At: 
Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Jun 2020 00:03:48 -0000

--00000000000035615905a6fa871e
Content-Type: text/plain; charset="UTF-8"

On Sat, 30 May 2020 at 17:59, Daniel Fett  wrote:

> Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE
> [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the
> conclusion that we have two options:
>
[..snip..]
> *2. "Dynamic" Solution*
>
> Each AS that supports PKCE MUST check whether a code challenge is
> contained in the authorization request. This information MUST be bound to
> the code that is issued.
>
> When a code arrives at the token endpoint, the AS MUST do the following
> check:
>
>    1. If there was a code_challenge in the authorization request for
>    which this code was issued, there must be a code_verifier in the token
>    request and it must be verified according to RFC7636. (This is no change
>    from the current behavior in RFC7636.)
>    2. If there was no code_challenge in the authorization request, any
>    request to the token endpoint containing a code_verifier MUST be rejected.
>
> Properties:
>
>    - No change in behavior needed for properly implemented clients.
>    Backwards compatible for all existing deployments.
>    - Implementation is mainly some logic for the authorization endpoint,
>    token endpoint, and a new data field in the authorization session
>    maintained by the AS.
>    - Slightly more complex to implement for the AS, maybe.
>
> We would like to hear the feedback from the working group on these two
> solutions before proceeding to propose wording for the affected documents.
>

When we added PKCE support in Firefox Accounts, we implemented the
suggested check (2) above purely as a defensive-coding measure, expecting
that it might help us catch buggy clients. I think it makes sense to add as
a required behaviour since it seems like a pretty clear signal of
mismatched expectations between client and server.

  Cheers,

     Ryan

--00000000000035615905a6fa871e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Sat, 30 May 2020 at 17:59, Daniel Fett <fett@danielfett.de> wrote:

 =20

   =20
 =20
  
Aaron, Dick, Torsten and I today
      discussed the downgrade attacks on PKCE [1] and how to mitigate
      them in OAuth 2.1 and 2.0. We came to the conclusion that we have
      two options:

    
[..snip..]

    
2. "Dynamic" Solution

      
Each AS that supports PKCE MUST check whether a code challenge
        is contained in the authorization request. This information MUST
        be bound to the code that is issued.

      
When a code arrives at the token endpoint, the AS MUST do the
        following check:

      
    
        
  1. If there was a code_challenge in the authorization request
          for which this code was issued, there must be a code_verifier
          in the token request and it must be verified according to
          RFC7636. (This is no change from the current behavior in
          RFC7636.)
    2. 
        
  2. If there was no code_challenge in the authorization request,
          any request to the token endpoint containing a code_verifier
          MUST be rejected.
    3. 
      

      
Properties:

      
    
        
  • No change in behavior needed for properly implemented
          clients. Backwards compatible for all existing deployments.
    
        
    • 
        
  • Implementation is mainly some logic for the authorization
          endpoint, token endpoint, and a new data field in the
          authorization session maintained by the AS.
    
        
    • 
        
  • Slightly more complex to implement for the AS, maybe.
    • 
      

    
We would like to hear the feedback from
      the working group on these two solutions before proceeding to
      propose wording for the affected documents.

   =20
    

When we added PKCE support in Fi=
refox Accounts, we implemented the suggested check (2) above purely as a de=
fensive-coding measure, expecting that it might help us catch buggy clients=
. I think it makes sense to add as a required behaviour since it seems like=
 a pretty clear signal of mismatched expectations between client and server=
.

=C2=A0 Cheers,

=C2=A0=
=C2=A0=C2=A0=C2=A0 Ryan


--00000000000035615905a6fa871e--


From nobody Sun May 31 23:28:00 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4F3A0D52 for ; Sun, 31 May 2020 23:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edWocnr8nb0H for ; Sun, 31 May 2020 23:27:57 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DBE3A0D51 for ; Sun, 31 May 2020 23:27:56 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id k19so6387761edv.9 for ; Sun, 31 May 2020 23:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=yPCI53mn7NBtx1UUKs5sSS4mEvlh8mQaR63FCnBIIes=; b=J3tUJ10Xdpg1KbE9uiXcYIjZyYAHtM7q+2v3vwqHf91sjHEnNwtrnJGP/1qmYCn/Qw Gl7M6XT68VwThcBI4GwoKRmUEKYTha0uuIdt5XjtW9248V3UQA/BfD0NxNaQHr3nP7tX /IhNlPcSOIOjKKUlkus7D0M/F6GMu5pLOl0s2q42nDxx4Zd/rukyeQO4i5YQoRqUzuEX T+2I6gzmv6KpDbgDKVQCmwlIenBwQiWB3drEg6F1dWrQToqOSGJOOHC3YjHuE7JG08RJ kG51MG4FrGUzkGiglF5Fd9UdZboR4396/hKrOn5hH9/Wf3b5xIUOaqsAQaczQ8NIUwVC /hLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=yPCI53mn7NBtx1UUKs5sSS4mEvlh8mQaR63FCnBIIes=; b=d4V3v6AC+XmM8KxroPOXMm+Opso6x6sn0ZfMtSSrGUKnKRxx0dCS/S7+vVjmL0kPkC D4cykPaCC7cFpxfEGzr/Rqxj0EmxLGHsptfj/R4BNNaR8uWBHu6qoTXUzBgvacBbLF1w VK4Egdl4+e4jiCMa0enM6zJUK4iimE4wnWFPI2K4do9TQKuJijh8GathAwBZyFDpcDO0 AP6mzoqLryPexWbSQwIsh0v4Uf2Bf/rNWppkgxy9p/U1GWsZtV/7WAkwTI9JzUotiwsj izLp8JHT9hoDJEmmos7GEalLqWPnhsr/TldWJ9jxaqvuRZH9oN7mUxlA8/qt+3lSvxev dCLg==
X-Gm-Message-State: AOAM533QiBbWlSdDkXCCQvNl/v92voAsTQgUktZcV2OILyZtGa84txPO wbgKG1zyZc05UkX8Tsb2/f7mDuAIkA==
X-Google-Smtp-Source: ABdhPJwP5AE4ITPbuYnKzDa0sfzf9zSgYAmf/UqR2pDFgpmHJYiT9WMgw76rC/Wfb+kvRKBx7qS7Ug==
X-Received: by 2002:a05:6402:959:: with SMTP id h25mr19711132edz.287.1590992869920;  Sun, 31 May 2020 23:27:49 -0700 (PDT)
Received: from [192.168.68.100] (173.c3.airnet.cz. [94.74.199.173]) by smtp.gmail.com with ESMTPSA id g23sm15644206edh.59.2020.05.31.23.27.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 May 2020 23:27:49 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-3F2B864A-D9A0-4832-AF82-7A1C12493746
Content-Transfer-Encoding: 7bit
From: Filip Skokan 
Mime-Version: 1.0 (1.0)
Date: Mon, 1 Jun 2020 08:27:48 +0200
Message-Id: <77B4ABEF-3233-4511-98D3-796121B67AC2@gmail.com>
References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
Cc: "oauth@ietf.org" 
In-Reply-To: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
To: Daniel Fett 
X-Mailer: iPhone Mail (17F75)
Archived-At: 
Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Jun 2020 06:27:59 -0000

--Apple-Mail-3F2B864A-D9A0-4832-AF82-7A1C12493746
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I also have #2 in place since ages like others have, or are about to.=20

It just made sense to me to have it that way based on PKCE Section 4.4.  The=
 challenge and method are bound to the code to be verified later.=20

When the server issues the authorization code in the authorization
   response, it MUST associate the "code_challenge" and
   "code_challenge_method" values with the authorization code so it can
   be verified later.

=E2=80=9CEmpty=E2=80=9D, =E2=80=9CUndefined=E2=80=9D and the like are values=
 to be verified too. The trigger to verify PKCE in the token request is pres=
ence of pkce params in either the code bound data or the request. Which woul=
d be the case described in Daniel=E2=80=99s blog post.=20

- Filip

Odesl=C3=A1no z iPhonu

> 30. 5. 2020 v 9:59, Daniel Fett :
>=20
> =EF=BB=BF
> Hi all,
>=20
> Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE [=
1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusion t=
hat we have two options:
>=20
> 1. "Static" Solution
>=20
> For every client_id that is registered with an AS, the AS MUST either alwa=
ys enforce the use of PKCE or always enforce the use of nonce. Whether PKCE o=
r nonce is enforced can be part of the client registration or configured in o=
ther ways.
>=20
> In other words: A single client is not allowed to switch between using PKC=
E and using nonce.
>=20
> Note that the client is allowed to use the respective other mechanism on t=
op of the enforced one.
>=20
> Properties:
> Easy to understand mitigation.
> Implementation is mainly a new data field and a check in the authorization=
 request.
> Not compatible to deployments where clients sometimes use nonce and someti=
mes use PKCE with the same client_id.=20
> 2. "Dynamic" Solution
>=20
> Each AS that supports PKCE MUST check whether a code challenge is containe=
d in the authorization request. This information MUST be bound to the code t=
hat is issued.
>=20
> When a code arrives at the token endpoint, the AS MUST do the following ch=
eck:
>=20
> If there was a code_challenge in the authorization request for which this c=
ode was issued, there must be a code_verifier in the token request and it mu=
st be verified according to RFC7636. (This is no change from the current beh=
avior in RFC7636.)
> If there was no code_challenge in the authorization request, any request t=
o the token endpoint containing a code_verifier MUST be rejected.
> Properties:
>=20
> No change in behavior needed for properly implemented clients. Backwards c=
ompatible for all existing deployments.
> Implementation is mainly some logic for the authorization endpoint, token e=
ndpoint, and a new data field in the authorization session maintained by the=
 AS.
> Slightly more complex to implement for the AS, maybe.
> We would like to hear the feedback from the working group on these two sol=
utions before proceeding to propose wording for the affected documents.
>=20
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>=20
> -Daniel
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-3F2B864A-D9A0-4832-AF82-7A1C12493746
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I also have #2 in place since ages like oth=
ers have, or are about to. 

It just made sense to me=
 to have it that way based on PKCE Section 4.4.  The challenge and meth=
od are bound to the code to be verified later. 

When the server issues the authorization c=
ode in the authorization
   response, it MUST associate the "code_challenge" and
   "code_challenge_method" values with the authorization code so it can
   be verified later.

=E2=80=9CEmpty=E2=80=9D, =E2=80=9CUndefin=
ed=E2=80=9D and the like are values to be verified too. The trigger to verif=
y PKCE in the token request is presence of pkce params in either the code bo=
und data or the request. Which would be the case described in Daniel=E2=80=99=
s blog post. 

- Filip

O=
desl=C3=A1no z iPhonu

30. 5. 2020 v 9:59, Daniel Fett <fett@danielfett.de>:

<=
/blockquote>
=EF=BB=BF
 =20

    
 =20
 =20
    
Hi all,

    

    


    

    
Aaron, Dick, Torsten and I today
      discussed the downgrade attacks on PKCE [1] and how to mitigate
      them in OAuth 2.1 and 2.0. We came to the conclusion that we have
      two options:

    


    

    
1. "Static" Solution

    


    

    
For every client_id that is registered
      with an AS, the AS MUST either always enforce the use of PKCE or
      always enforce the use of nonce. Whether PKCE or nonce is enforced
      can be part of the client registration or configured in other
      ways.

    


    

    
In other words: A single client is not
      allowed to switch between using PKCE and using nonce.

    

    


    

    
Note that the client is allowed to use
      the respective other mechanism on top of the enforced one.

    


    

    
Properties:

    

      
    
        
  • Easy to understand mitigation.
    
        
    • 
        
  • Implementation is mainly a new data field and a check in the
          authorization request.
    • 
        
  • Not compatible to deployments where clients sometimes use
          nonce and sometimes use PKCE with the same client_id. 
    
               
    • 
      

       
      
2. "Dynamic" Solution

      
Each AS that supports PKCE MUST check whether a code challenge
        is contained in the authorization request. This information MUST
        be bound to the code that is issued.

      
When a code arrives at the token endpoint, the AS MUST do the
        following check:

      
    
        
  1. If there was a code_challenge in the authorization request
          for which this code was issued, there must be a code_verifier
          in the token request and it must be verified according to
          RFC7636. (This is no change from the current behavior in
          RFC7636.)
    2. 
        
  2. If there was no code_challenge in the authorization request,
          any request to the token endpoint containing a code_verifier
          MUST be rejected.
    3. 
      

      
Properties:

      
    
        
  • No change in behavior needed for properly implemented
          clients. Backwards compatible for all existing deployments.
    
        
    • 
        
  • Implementation is mainly some logic for the authorization
          endpoint, token endpoint, and a new data field in the
          authorization session maintained by the AS.
    
        
    • 
        
  • Slightly more complex to implement for the AS, maybe.
    • 
      

    

    
We would like to hear the feedback from
      the working group on these two solutions before proceeding to
      propose wording for the affected documents.

    

    


    

    
[1] https://danielfett.de/2020/05/16/pk=
ce-vs-nonce-equivalent-or-not/

    


    

    
-Daniel

    


    

 =20

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

--Apple-Mail-3F2B864A-D9A0-4832-AF82-7A1C12493746--


On Tue, May 19, 2020 at 7:20 AM Filip Skokan <panva.ip@gmail.com> wr=
ote:
This is a RE: to yesterday's interim meeting discussion, lar=
gely related to the first rollout step where we want to constrain refresh t=
okens but leave protected resource access intact.

<=
div>I'll start off with a case that I hope we can agree=C2=A0is absolut=
ely necessary for DPoP to solve - that is constraining refresh tokens for b=
rowser based applications. Now, do we see this as a secondary objective?=
 I think it should be on par with access token constraining.=C2=A0SPAs =
using code flow and having access to refresh tokens as means against the co=
ntinuous browser efforts to cut down on storage access is a real case serve=
rs will be eventually forced to adopt.

Since rollo=
ut for DPoP needs to begin with the AS and Client supporting it (regardless=
 what order i guess) there are going to be instances where the RS will be s=
upporting both Bearer and DPoP at the same time.

A=
s discussed yesterday, the client shouldn't know/care and change its be=
haviour when it comes to using access tokens.

B=
ut what is the client behaviour we take for standard? Because I can see=
 two conflicting implementations in the wild
  1. The client e=
choes the token_type it received from the token endpoint as the authorizati=
on scheme
    • (optionally) throws on unrecognized token type values=

  2. The client uses Bearer as a fixed authorization scheme and ig=
nores the token_type it received
#2 is an implementation whic=
h I suspect has no idea about DPoP, but if extended to send DPoP headers (t=
hrough various mechanism - library extensions or even manipulating the `XML=
HttpRequest` prototype) will
  • =F0=9F=8E=89 get the benefit=
 of having its Refresh Tokens bound
  • =F0=9F=8E=89 most likely contin=
ue to work with RSs that only support Bearer
  • =E2=9D=8C will cease t=
o work with RSs that will adopt support for DPoP because it'll be using=
 the wrong scheme, that is unless (=F0=9F=8E=89) RSs supporting DPoP choose=
 to suspend the requirement to use the new scheme and instead depend on the=
 presence of `cnf.jkt` as means to trigger DPoP validation. Q: is that a=
n acceptable thing to do?
Arguably, client behaviou=
r #1 is what a client should be using if it supports other=C2=A0schemes bes=
ides Bearer. But it may as well be the behaviour of a client that has no cl=
ue about DPoP, right? Again, such client can be made to support DPoP in a S=
PA through manipulation of the=C2=A0XMLHttpRequest prototype, in which case=
 the developer needs to do the same for the=C2=A0protected resource calls. =
But at this point the developer has to know which RS to apply DPoP to and w=
hich not - ergo - which to send Bearer vs. DPoP scheme to? The developer wi=
ll have to write a whitelist of resource servers anyway - and there we get =
to the point where client has information and functionality that it shouldn=
't /need to/ have.

Its great that we hav=
e token_type, authorization header schemes, etc..., but we don't seem h=
ave a well defined (or at least followed) behaviour for our clients around =
handling the token_type response values and their usage.

A developer has to resolve to navigate this monkey course unless the=
 RS definition on the AS is aware of the fact that the RS does support=C2=
=A0DPoP, so that the issued token_type is always correct for the RS. So, should we make that a recommended way of 'indicating' when to issu=
e Bearer vs DPoP access tokens?

What el=
se could we do that doesn't give more decision making to the clients so=
 that the very first step -=C2=A0Refresh Tokens get constrained=C2=
=A0- is achieved but Protected Resource access is unaffected?
<=
div>
Note that this was not "a thing" for mT=
LS because it continues to use the Bearer scheme (for better or worse) and =
it completely=C2=A0omits possible continuous rollout or discussing what are=
 the signals the RS must use to require mTLS to be used), same for the aban=
doned OAuth 2.0 Token Binding draft (also continued to use the Bearer schem=
e).=C2=A0

I suspect we have just this opportunity =
to fix token types and their use and if we can't, we'll have to res=
olve to abandon that extension point as one that doesn't support contin=
ued rollout of real sender constraining mechanism (e.g. http signatures in =
the future) and just continue using Bearer because in the end, given that R=
Ss could be relying on the presence of the cnf claim to figure out the toke=
n's constraining mechanism, would that be such a bad thing?
<=
br>
Put it the other way around. By introducing Bearer scheme, do=
 we actually gain anything of value that can't be gained through other =
means?

Note that this message didn't start wit=
h the goal of questioning the new scheme use, it just sort of landed there.=
.. My pedantic nature would love to see the new scheme and token_type exten=
sion point used as it was meant to be but I also recognize the many issues =
it brings that could be sidestepped by not introducing it in the first plac=
e, all without losing capabilities.

Previous mater=
ial on the topic

S pozdravem,
Filip Skokan

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


Hi,

This is=
 a working group last call for "JWT Response for OAuth Token Introspec=
tion".
This documented was returned to the WG after a number=
 of=C2=A0 important changes during the IESG review.

Here is the document:

Please send your comments to the OAuth mailing list by May 22, 2020.<=
/div>

Regards,
=C2=A0Rifaat & Hannes
=



--00000000000063b40205a539c03f--


From nobody Sat May  9 11:46:21 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733A93A0E9C for ; Sat,  9 May 2020 11:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tymxvWECokie for ; Sat,  9 May 2020 11:46:11 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650127.outbound.protection.outlook.com [40.107.65.127]) (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 2252B3A0E90 for ; Sat,  9 May 2020 11:46:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JgWuFeVJMfeDeruiVKqH+ww4t0PyDZlp/So4hVan3jCD6WgZf8IbeJRJcbfJ8h25zSl9WL11FrTdWx4P64uV/s+ll0K951oJ5FM91k4O7aPprJYuAN1pgSA9J9fVhqT8XahPT54LT06kazU/3I0eaQh1R2uTCdAaw2h2HQlCxCgsfakt1isQRVnVIgBG/ZTsX7EumlTwKO8yp243+3VmDGRqmb2F4//szNW1BxFjE7y2nn0gOd+W6rioBKRKQVwqA0oc7uQT3LE3YAbrMAENbrnpEHHRoI/AybULZcgSnLkZzs65vWLxHg6kq01ShFlCCgct6jJbKiUh+EAO4Xmf9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=owj9obY/aECslOJYumHkRA8B6t2uhkwXXcB9RirNPJ4=; b=fWKkhPM8EA1Xq1MlnbdGLVqamKmL+jOh/wL0FTJYRma7avMS4tbxO/5o+o36zRGuAlZRVpy3sGq+rAohagDGdigrQVhz4CpPCqJewm7fJO8MiDDF/TOz/cwe0YxcftVi85sRg5xORO3jQLo8rggPXSEvnkh4Bwkx1uRlaGKKbRno0WeyJBdq1lgmkNN7/WRIgNxw+/l2+xneXasg0wkZlj3sdGwBvBAu/vEfe/YV4F0Ly5CDFWKJN+tOLTbRKk+lJcyEQhf94IatgHxJdKNvFJk1JJL4ON3ot0Ptd+zD2OmEfITrcHOwbdFib7E3pLpn7QmPiaguhQJxM52S0LG3Ug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=owj9obY/aECslOJYumHkRA8B6t2uhkwXXcB9RirNPJ4=; b=jOfJXYlcmFsa8W7T6YzYud2KNz2UuZrZ4CWNmMI09ULUeZgrDEA6inLGS5e+GBU7tGZAPtPwU+RyXGW9TWoHUHYGQWEJGOnfRTxGrATTyEAEGGxF68lVQ1z8N8MKCElvGjZtHwpvu3gTQhiipDpOtbj7+aAfPEUtzWmuPi5fkm4=
Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM6PR00MB0848.namprd00.prod.outlook.com (2603:10b6:5:1bf::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3028.0; Sat, 9 May 2020 18:45:38 +0000
Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::1834:c740:72aa:48dc]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::1834:c740:72aa:48dc%9]) with mapi id 15.20.3027.000; Sat, 9 May 2020 18:45:38 +0000
From: Mike Jones 
To: Aaron Parecki , OAuth WG 
Thread-Topic: OAuth 2.1 - require PKCE?
Thread-Index: AdYmMgUsc1wsS0y1Tjm0HaaofVULyg==
Date: Sat, 9 May 2020 18:45:38 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=46d1b4da-36ff-4fa2-b9f6-0000b32053e3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-09T18:38:30Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: fa6d0154-121a-4620-4c83-08d7f4492afe
x-ms-traffictypediagnostic: DM6PR00MB0848:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 03982FDC1D
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RQ+6422gfsv4NiAS06fc6Yjdb5FNt30eNr+bDgCQCPv/8gJ+Yw/t2hGv6DjCc3NJmWS7uCdplKR2F7644g0URoOQgbiqdA4YNaIe0pVr1NsrdALDwKpf9b/hT3y7uQVYix95+KLFAQVThcXb5kznZ0gL3fp3iVf/eyIfZZWFWE4fLhtJmDkb33mm64CIYnDjWPHV89nBMePTUypwf6aWTYHsLIMMH963dc8PvJqvvww1WQ2IgzG0AArrnkMtjeKHr9JdnYlmxKI93S2enDe6vkjv4OrThCmN+IXPwLl43newI6DEm8vsKhxqkVThZ8WFLtaL3PZHxQhqBKNggGI3Bz6JGurGgBTVxe+bBxK6A+f6LS43My5Buq7DR/pGG4o8BuTqEXYzxPLN7psdzTrX6KZZG5E/NRZJWMnn73OyFHQ5HI+qu8+P0/BDWHNoOMEZ
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM6PR00MB0682.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(376002)(346002)(366004)(33430700001)(54906003)(316002)(110136005)(53546011)(6506007)(52536014)(8676002)(10290500003)(86362001)(33656002)(82950400001)(66574014)(7696005)(55016002)(26005)(9686003)(76236002)(186003)(4326008)(5660300002)(478600001)(71200400001)(66446008)(64756008)(66556008)(66946007)(66476007)(8990500004)(8936002)(33440700001)(2906002)(82960400001)(76116006)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: XDm0bIed/+vG2t8dj1X7+K+ftyA657+ETvousKFoTcI18f4kL2q08M9XDIdHF/n16CaGML6v8ZhiBZhcuGsCC4YSIG8PPS9+EOYdzNbehIGN49lGLHw8ev1mNglcP+D7fYq7keyf4ymWwcc7h2AKKqAAIwYSXUT0IbeBgxEeRqu9AsuNuOwssM9fdl3Tg52E9FehLvJJRAHt2ZZsqhDV6eXVd+Myh+1fGYbNFqa1oV+oVD1P4go7Udnk/eonr8BaHPcnx/0KukOoZBDFpP04tfwFwvaYeGLyVxKSoosCmcuj6NmcHVW/MQCy+Ot7H/Gm6sE0/Mek0iRUVTBcKsvxp7vguRoo2ONqSXFKZ3P5vNiaWkXWBs8xEGYZGHplg4dY1c0x9ctvXh1N+1BBt/r6Qf6hYHoHxhjqyoIKRveLBenqqClROufcJunyNsc1T7EVp0G4kLUoGPP3FaMQzkuknH+4xPRm+7ZS6uSj2bct7Xk=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06824211CEC46217264F4F60F5A30DM6PR00MB0682namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0682.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa6d0154-121a-4620-4c83-08d7f4492afe
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2020 18:45:38.6885 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6/ZIp00gU/GWyTQ3ItciiQUCBCx4i8VQSjXn6dJQ3JBA7Hi+KEVlPg7AbGcv7BI5s8Ctyd/+WtiQ2J99S6PwQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0848
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 May 2020 18:46:18 -0000

--_000_DM6PR00MB06824211CEC46217264F4F60F5A30DM6PR00MB0682namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlcmXigJlzIGEgaHVnZSBlY29zeXN0ZW0gb2Ygc3VjY2Vzc2Z1bCwgc2VjdXJlIE9BdXRoIDIu
MCBhbmQgT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHMgdGhhdCB3ZSBoYXZlIHRoZSByZXNwb25z
aWJpbGl0eSB0byBiZSBzdGV3YXJkcyBvZi4gIFRoaXMgd29ya2luZyBncm91cCBzaG91bGQgYmUg
cHJvdWQgb2Ygd2hhdCBpdOKAmXMgYWNjb21wbGlzaGVkLiAgUGFydCBvZiBnb29kIHN0ZXdhcmRz
aGlwIGlzIG5vdCB1bm5lY2Vzc2FyaWx5IGJpZnVyY2F0aW5nIHRoZSBlY29zeXN0ZW0gaW50byBu
b24taW50ZXJvcGVyYWJsZSBzZWdtZW50cy4gIE9BdXRoIDIuMSBzaG91bGQgZmFjaWxpdGF0ZSB0
aGUgYWxyZWFkeSBzZWN1cmUgT0F1dGggMi4wIGRlcGxveW1lbnRzIHJlbWFpbmluZyBwYXJ0IG9m
IHRoZSBpbnRlcm9wZXJhYmxlIE9BdXRoIDIuMSBzZXQgb2YgZGVwbG95bWVudHMg4oCTIG5vdCBp
bnRlbnRpb25hbGx5IGRvaW5nIHRoZSBvcHBvc2l0ZS4NCg0KSWYgaXQgYWlu4oCZdCBicm9rZSwg
ZG9u4oCZdCBmaXggaXQhDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEFhcm9uIFBhcmVja2kgPGFhcm9uQHBh
cmVja2kuY29tPg0KU2VudDogRnJpZGF5LCBNYXkgOCwgMjAyMCA4OjM0IFBNDQpUbzogT0F1dGgg
V0cgPG9hdXRoQGlldGYub3JnPg0KQ2M6IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29t
PjsgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+OyBNaWtlIEpv
bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSZTogT0F1dGggMi4x
IC0gcmVxdWlyZSBQS0NFPw0KDQpBYXJvbiwgSSBiZWxpZXZlIHlvdeKAmXJlIHRyeWluZyB0byBv
cHRpbWl6ZSB0aGUgd3JvbmcgdGhpbmcuICBZb3XigJlyZSBjb25jZXJuZWQgYWJvdXQg4oCcdGhl
IGFtb3VudCBvZiBleHBsYW5hdGlvbiB0aGlzIHdpbGwgdGFrZeKAnS4gIFRoYXTigJlzIG9wdGlt
aXppbmcgZm9yIHNwZWMgc2ltcGxpY2l0eSDigJMgYSBnb2FsIHRoYXQgSSBkbyB1bmRlcnN0YW5k
LiAgSG93ZXZlciwgYnkgd3JpdGluZyB0aGVzZSBmZXcgc2VudGVuY2VzIG9yIHBhcmFncmFwaHMs
IHdl4oCZbGwgbWFrZSBpdCBjbGVhciB0byBkZXZlbG9wZXJzIHRoYXQgaHVuZHJlZHMgb3IgdGhv
dXNhbmRzIG9mIGRlcGxveWVkIE9wZW5JRCBDb25uZWN0IFJQcyB3b27igJl0IGhhdmUgdG8gY2hh
bmdlIHRoZWlyIGRlcGxveW1lbnRzLiAgVGhhdOKAmXMgb3B0aW1pemluZyBmb3IgaW50ZXJvcGVy
YWJpbGl0eSBhbmQgbWluaW1pemluZyB0aGUgYnVyZGVuIG9uIGRldmVsb3BlcnMsIHdoaWNoIGFy
ZSBmYXIgbW9yZSBpbXBvcnRhbnQuDQoNCkkgYXBwcmVjaWF0ZSB0aGUgY29uY2VybiBhYm91dCBv
cHRpbWl6aW5nIGZvciBzcGVjIHNpbXBsaWNpdHkuIEkgYWxzbyBhZ3JlZSB0aGF0IHNwZWMgc2lt
cGxpY2l0eSBzaG91bGQgbm90IG5lY2Vzc2FyaWx5IGJlIHRoZSBkcml2aW5nIGdvYWwuDQoNCkhv
d2V2ZXIsIHdoYXQgeW91J3ZlIGRlc2NyaWJlZCBpcyB0aGUgb3Bwb3NpdGUgb2YgaW50ZXJvcGVy
YWJpbGl0eSBhbmQgbWluaW1pemluZyB0aGUgYnVyZGVuIG9uIGRldmVsb3BlcnMuIFJlcXVpcmlu
ZyBQS0NFIGluIE9BdXRoIDIuMSwgd2l0aG91dCBhbnkgZXhjZXB0aW9ucywgd2lsbCBvcHRpbWl6
ZSBmb3IgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIE9BdXRoIDIuMSBjbGllbnRzIGFuZCBzZXJ2
ZXJzLiBXaXRob3V0IHRoZSByZXF1aXJlbWVudCBvZiBQS0NFLCB0aGVyZSB3aWxsIGFsd2F5cyBi
ZSB0aGUgcXVlc3Rpb24gb2YgImJ1dCBkb2VzIHRoaXMgT0F1dGggMi4xIGNsaWVudCB3b3JrIHdp
dGggdGhpcyBPQXV0aCAyLjEgc2VydmVyIG9yIG5vdD8iLCB3aGljaCB3aWxsIG9ubHkgYmUgYWJs
ZSB0byBiZSBhbnN3ZXJlZCBieSBpbnZlc3RpZ2F0aW5nIHRoZSBkb2NzIHRvIGxvb2sgZm9yIFBL
Q0Ugc3VwcG9ydCwgb3IgYnkgY2hlY2tpbmcgdGhlIEFTIG1ldGFkYXRhIGRvY3VtZW50IGlmIGl0
IHB1Ymxpc2hlcyBvbmUgKHdoaWNoIGl0IGlzIG5vdCByZXF1aXJlZCB0byBkbykuDQoNCk9wdGlt
aXppbmcgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIG1pbmltaXppbmcgdGhlIGJ1cmRlbiBvbiBk
ZXZlbG9wZXJzIGlzIGFic29sdXRlbHkgYSBnb29kIGdvYWwsIGFuZCByZXF1aXJpbmcgUEtDRSBp
cyBhIGdyZWF0IHdheSB0byBhY2NvbXBsaXNoIHRoYXQuIE9BdXRoIDIuMCBhbmQgT3BlbklEIENv
bm5lY3QgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3Qgc3VwcG9ydCBQS0NFIHdpbGwgY29udGlu
dWUgdG8gd29yayBhcyB0aGV5IGN1cnJlbnRseSBkbywgdGhleSBqdXN0IHdvbid0IGJlIGFibGUg
dG8gY2FsbCB0aGVtc2VsdmVzIE9BdXRoIDIuMSBjb21wbGlhbnQsIGp1c3QgYXMgaXMgdGhlIGNh
c2UgYXMgaWYgdGhleSBkb24ndCBmb2xsb3cgdGhlIG90aGVyIHJlY29tbWVuZGF0aW9ucyB0aGF0
IGFyZSBpbiBPQXV0aCAyLjEgYW5kIHRoZSBTZWN1cml0eSBCQ1AuDQoNCkFhcm9uDQoNCg0KT24g
VGh1LCBNYXkgNywgMjAyMCBhdCA2OjQyIFBNIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpB
YXJvbiwgSSBiZWxpZXZlIHlvdeKAmXJlIHRyeWluZyB0byBvcHRpbWl6ZSB0aGUgd3JvbmcgdGhp
bmcuICBZb3XigJlyZSBjb25jZXJuZWQgYWJvdXQg4oCcdGhlIGFtb3VudCBvZiBleHBsYW5hdGlv
biB0aGlzIHdpbGwgdGFrZeKAnS4gIFRoYXTigJlzIG9wdGltaXppbmcgZm9yIHNwZWMgc2ltcGxp
Y2l0eSDigJMgYSBnb2FsIHRoYXQgSSBkbyB1bmRlcnN0YW5kLiAgSG93ZXZlciwgYnkgd3JpdGlu
ZyB0aGVzZSBmZXcgc2VudGVuY2VzIG9yIHBhcmFncmFwaHMsIHdl4oCZbGwgbWFrZSBpdCBjbGVh
ciB0byBkZXZlbG9wZXJzIHRoYXQgaHVuZHJlZHMgb3IgdGhvdXNhbmRzIG9mIGRlcGxveWVkIE9w
ZW5JRCBDb25uZWN0IFJQcyB3b27igJl0IGhhdmUgdG8gY2hhbmdlIHRoZWlyIGRlcGxveW1lbnRz
LiAgVGhhdOKAmXMgb3B0aW1pemluZyBmb3IgaW50ZXJvcGVyYWJpbGl0eSBhbmQgbWluaW1pemlu
ZyB0aGUgYnVyZGVuIG9uIGRldmVsb3BlcnMsIHdoaWNoIGFyZSBmYXIgbW9yZSBpbXBvcnRhbnQu
DQoNCkFzIEJyaWFuIENhbXBiZWxsIHdyb3RlLCDigJxUaGV5IGFyZSBub3QgZXF1aXZhbGVudCBh
bmQgaGF2ZSB2ZXJ5IGRpZmZlcmVudCByYW1pZmljYXRpb25zIG9uIGludGVyb3BlcmFiaWxpdHni
gJ0uDQoNCkV2ZW4gaWYgeW914oCZcmUgb3B0aW1pemluZyBmb3Igd3JpdGluZywgdGFraW5nIGEg
bWluaW1hbGx5IGludmFzaXZlIHByb3RvY29sIGNoYW5nZSBhcHByb2FjaCB3aWxsIG9wdGltaXpl
IHRoYXQsIG92ZXJhbGwuICBJZiB3ZSBwcm9jZWVkIGFzIHlvdeKAmXJlIHN1Z2dlc3RpbmcsIGEg
aHVnZSBhbW91bnQgb2Ygd3JpdGluZyB3aWxsIG9jY3VyIG9uIFN0YWNrT3ZlcmZsb3csIE1lZGl1
bSwgU2xhc2hEb3QsIGJsb2dzLCBhbmQgb3RoZXIgZGV2ZWxvcGVyIGZvcnVtcywgd2hlcmUgY29u
ZnVzZWQgZGV2ZWxvcGVycyB3aWxsIGFzayDigJxXaHkgZG8gSSBoYXZlIHRvIGNoYW5nZSBteSBk
ZXBsb3llZCBjb2RlP+KAnSB3aXRoIHRoZSBhbnN3ZXJzIGJlaW5nIOKAnERlc3BpdGUgd2hhdCB0
aGUgMi4xIHNwZWMgc2F5cywgdGhlcmXigJlzIG5vIG5lZWQgdG8gY2hhbmdlIHlvdXIgZGVwbG95
ZWQgY29kZS7igJ0NCg0KSeKAmWQgZ2xhZGx5IHdyaXRlIGEgZmV3IHNlbnRlbmNlcyBpbiBvdXIg
bmV3IHNwZWNzIG5vdyB0byBwcmV2ZW50IG9uZ29pbmcgY29uZnVzaW9uIGFuZCBpbnRlcm9wIHBy
b2JsZW1zIHRoYXQgd291bGQgb3RoZXJ3aXNlIHJlc3VsdC4gIExldCBtZSBrbm93IHdoZW4geW91
4oCZcmUgcmVhZHkgdG8gaW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSBzcGVjIHRleHQuDQoNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN
aWtlDQoNCkZyb206IEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJv
bkBwYXJlY2tpLmNvbT4+DQpTZW50OiBUaHVyc2RheSwgTWF5IDcsIDIwMjAgNDozOSBQTQ0KVG86
IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWls
LmNvbT4+DQpDYzogT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y
Zz4+OyBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86
dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KU3ViamVjdDog
UmU6IE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KQmFja2luZyB1cCBhIHN0ZXAgb3IgdHdv
LCB0aGVyZSdzIGFub3RoZXIgcG9pbnQgaGVyZSB0aGF0IEkgdGhpbmsgaGFzIGJlZW4gbWlzc2Vk
IGluIHRoZXNlIGRpc2N1c3Npb25zLg0KDQpQS0NFIHNvbHZlcyB0d28gcHJvYmxlbXM6IHN0b2xl
biBhdXRob3JpemF0aW9uIGNvZGVzIGZvciBwdWJsaWMgY2xpZW50cywgYW5kIGF1dGhvcml6YXRp
b24gY29kZSBpbmplY3Rpb24gZm9yIGFsbCBjbGllbnRzLiBXZSd2ZSBvbmx5IGJlZW4gdGFsa2lu
ZyBhYm91dCBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIG9uIHRoZSBsaXN0IHNvIGZhci4g
VGhlIHF1b3RlZCBzZWN0aW9uIG9mIHRoZSBzZWN1cml0eSBCQ1AgKDQuNS4zKSB3aGljaCBzYXlz
IGNsaWVudHMgY2FuIGRvIFBLQ0Ugb3IgdXNlIHRoZSBub25jZSwgaXMgb25seSB0YWxraW5nIGFi
b3V0IHByZXZlbnRpbmcgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbi4NCg0KVGhlIG5vbmNl
IHBhcmFtZXRlciBzb2x2ZXMgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBpZiB0aGUgY2xp
ZW50IHJlcXVlc3RzIGFuIElEIHRva2VuLiBQdWJsaWMgY2xpZW50cyB1c2luZyB0aGUgbm9uY2Ug
cGFyYW1ldGVyIGFyZSBzdGlsbCBzdXNjZXB0aWJsZSB0byBzdG9sZW4gYXV0aG9yaXphdGlvbiBj
b2RlcyBzbyB0aGV5IHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBhcyB3ZWxsLg0KDQpUaGUgb25seSBj
YXNlIHdoZXJlIE9wZW5JRCBDb25uZWN0IGNsaWVudHMgZG9uJ3QgYmVuZWZpdCBmcm9tIFBLQ0Ug
aXMgaWYgdGhleSBhcmUgYWxzbyBjb25maWRlbnRpYWwgY2xpZW50cy4gUHVibGljIGNsaWVudCBP
SURDIGNsaWVudHMgc3RpbGwgbmVlZCB0byBkbyBQS0NFIGV2ZW4gaWYgdGhleSBjaGVjayB0aGUg
bm9uY2UuDQoNCk9wZW5JRCBDb25uZWN0IHNlcnZlcnMgd29ya2luZyB3aXRoIGNvbmZpZGVudGlh
bCBjbGllbnRzIHN0aWxsIGJlbmVmaXQgZnJvbSBQS0NFIGJlY2F1c2UgdGhleSBjYW4gdGhlbiBl
bmZvcmNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIHByb3RlY3Rpb24gc2VydmVy
LXNpZGUgcmF0aGVyIHRoYW4gY3Jvc3MgdGhlaXIgZmluZ2VycyB0aGF0IGNsaWVudHMgaW1wbGVt
ZW50ZWQgdGhlIG5vbmNlIGNoZWNrIHByb3Blcmx5Lg0KDQpJIHJlYWxseSBkb24ndCB0aGluayBp
dCdzIHdvcnRoIHRoZSBhbW91bnQgb2YgZXhwbGFuYXRpb24gdGhpcyB3aWxsIHRha2UgaW4gdGhl
IGZ1dHVyZSB0byB3cml0ZSBhbiBleGNlcHRpb24gaW50byBPQXV0aCAyLjEgb3IgdGhlIFNlY3Vy
aXR5IEJDUCBmb3Igb25seSBzb21lIHR5cGVzIG9mIE9wZW5JRCBDb25uZWN0IGNsaWVudHMgd2hl
biBhbGwgY2xpZW50cyB3b3VsZCBiZW5lZml0IGZyb20gUEtDRSBhbnl3YXkuDQoNCkFhcm9uDQoN
Cg0KDQpPbiBXZWQsIE1heSA2LCAyMDIwIGF0IDEwOjQ4IEFNIERpY2sgSGFyZHQgPGRpY2suaGFy
ZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KSGVsbG8h
DQoNCldlIHdvdWxkIGxpa2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29k
ZSBmbG93cy4gVGhpcyBpcyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBj
b21tb24gaW4gT3BlbklEIENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUg
b2YgdGhlIGlzc3VlcyB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsgdGhhdCBt
b3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1dGggMi4w
LCBhbmQgaGVuY2UgaGF2ZSBzdXBwb3J0IGZvciBQS0NFIGlmIGZvbGxvd2luZyBiZXN0IHByYWN0
aWNlcy4NCg0KVGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOg0KDQotIGEgc2lt
cGxlciBwcm9ncmFtbWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0aW9ucyBhbmQg
cHJvZmlsZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0UNCg0KLSByZWR1Y2VkIGF0dGFjayBzdXJmYWNl
IHdoZW4gdXNpbmcgIFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZpZXIgaXMgc2Vu
dCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQgdmFsdWUNCg0K
LSBlbmZvcmNlbWVudCBieSBBUyBub3QgY2xpZW50IC0gbWFrZXMgaXQgZWFzaWVyIHRvIGhhbmRs
ZSBmb3IgY2xpZW50IGRldmVsb3BlcnMgYW5kIEFTIGNhbiBlbnN1cmUgdGhlIGNoZWNrIGlzIGNv
bmR1Y3RlZA0KDQpXaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVudGlhbCBp
bXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2FudCBpcyB0
aGF0IGltcGFjdD8NCg0KRGljaywgQWFyb24sIGFuZCBUb3JzdGVuDQoNCuGQpw0K

--_000_DM6PR00MB06824211CEC46217264F4F60F5A30DM6PR00MB0682namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K
CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
VGhlcmXigJlzIGEgaHVnZSBlY29zeXN0ZW0gb2Ygc3VjY2Vzc2Z1bCwgc2VjdXJlIE9BdXRoIDIu
MCBhbmQgT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHMgdGhhdCB3ZSBoYXZlIHRoZSByZXNwb25z
aWJpbGl0eSB0byBiZSBzdGV3YXJkcyBvZi4mbmJzcDsgVGhpcyB3b3JraW5nIGdyb3VwIHNob3Vs
ZCBiZSBwcm91ZCBvZiB3aGF0IGl04oCZcyBhY2NvbXBsaXNoZWQuJm5ic3A7IFBhcnQNCiBvZiBn
b29kIHN0ZXdhcmRzaGlwIGlzIG5vdCB1bm5lY2Vzc2FyaWx5IGJpZnVyY2F0aW5nIHRoZSBlY29z
eXN0ZW0gaW50byBub24taW50ZXJvcGVyYWJsZSBzZWdtZW50cy4mbmJzcDsgT0F1dGggMi4xIHNo
b3VsZCBmYWNpbGl0YXRlIHRoZSBhbHJlYWR5IHNlY3VyZSBPQXV0aCAyLjAgZGVwbG95bWVudHMg
cmVtYWluaW5nIHBhcnQgb2YgdGhlIGludGVyb3BlcmFibGUgT0F1dGggMi4xIHNldCBvZiBkZXBs
b3ltZW50cyDigJMgbm90IGludGVudGlvbmFsbHkgZG9pbmcNCiB0aGUgb3Bwb3NpdGUuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JZiBpdCBhaW7igJl0IGJyb2tlLCBkb27i
gJl0IGZpeCBpdCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBBYXJvbiBQYXJlY2tpICZsdDthYXJvbkBw
YXJlY2tpLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDgsIDIwMjAgODoz
NCBQTTxicj4NCjxiPlRvOjwvYj4gT0F1dGggV0cgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4N
CjxiPkNjOjwvYj4gRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7OyBUb3Jz
dGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDs7IE1pa2UgSm9u
ZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uLCBJIGJlbGlldmUgeW914oCZcmUgdHJ5
aW5nIHRvIG9wdGltaXplIHRoZSB3cm9uZyB0aGluZy4mbmJzcDsgWW914oCZcmUgY29uY2VybmVk
IGFib3V0IOKAnHRoZSBhbW91bnQgb2YgZXhwbGFuYXRpb24gdGhpcyB3aWxsIHRha2XigJ0uJm5i
c3A7IFRoYXTigJlzIG9wdGltaXppbmcgZm9yIHNwZWMgc2ltcGxpY2l0eSDigJMgYSBnb2FsIHRo
YXQgSSBkbyB1bmRlcnN0YW5kLiZuYnNwOyBIb3dldmVyLCBieSB3cml0aW5nIHRoZXNlIGZldyBz
ZW50ZW5jZXMNCiBvciBwYXJhZ3JhcGhzLCB3ZeKAmWxsIG1ha2UgaXQgY2xlYXIgdG8gZGV2ZWxv
cGVycyB0aGF0IGh1bmRyZWRzIG9yIHRob3VzYW5kcyBvZiBkZXBsb3llZCBPcGVuSUQgQ29ubmVj
dCBSUHMgd29u4oCZdCBoYXZlIHRvIGNoYW5nZSB0aGVpciBkZXBsb3ltZW50cy4mbmJzcDsgVGhh
dOKAmXMgb3B0aW1pemluZyBmb3IgaW50ZXJvcGVyYWJpbGl0eSBhbmQgbWluaW1pemluZyB0aGUg
YnVyZGVuIG9uIGRldmVsb3BlcnMsIHdoaWNoIGFyZSBmYXIgbW9yZSBpbXBvcnRhbnQuPG86cD48
L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IGFwcHJlY2lhdGUgdGhlIGNvbmNlcm4gYWJvdXQgb3B0aW1pemluZyBmb3Igc3BlYyBzaW1wbGlj
aXR5LiBJIGFsc28gYWdyZWUgdGhhdCBzcGVjIHNpbXBsaWNpdHkgc2hvdWxkIG5vdCBuZWNlc3Nh
cmlseSBiZSB0aGUgZHJpdmluZyBnb2FsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCB3aGF0IHlvdSd2ZSBkZXNjcmliZWQgaXMg
dGhlIG9wcG9zaXRlIG9mIGludGVyb3BlcmFiaWxpdHkgYW5kIG1pbmltaXppbmcgdGhlIGJ1cmRl
biBvbiBkZXZlbG9wZXJzLiBSZXF1aXJpbmcgUEtDRSBpbiBPQXV0aCAyLjEsIHdpdGhvdXQgYW55
IGV4Y2VwdGlvbnMsIHdpbGwgb3B0aW1pemUgZm9yIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBP
QXV0aCAyLjEgY2xpZW50cyBhbmQgc2VydmVycy4gV2l0aG91dA0KIHRoZSByZXF1aXJlbWVudCBv
ZiBQS0NFLCB0aGVyZSB3aWxsIGFsd2F5cyBiZSB0aGUgcXVlc3Rpb24gb2YgJnF1b3Q7YnV0IGRv
ZXMgdGhpcyBPQXV0aCAyLjEgY2xpZW50IHdvcmsgd2l0aCB0aGlzIE9BdXRoIDIuMSBzZXJ2ZXIg
b3Igbm90PyZxdW90Oywgd2hpY2ggd2lsbCBvbmx5IGJlIGFibGUgdG8gYmUgYW5zd2VyZWQgYnkg
aW52ZXN0aWdhdGluZyB0aGUgZG9jcyB0byBsb29rIGZvciBQS0NFIHN1cHBvcnQsIG9yIGJ5IGNo
ZWNraW5nIHRoZSBBUyBtZXRhZGF0YQ0KIGRvY3VtZW50IGlmIGl0IHB1Ymxpc2hlcyBvbmUgKHdo
aWNoIGl0IGlzIG5vdCByZXF1aXJlZCB0byBkbykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9wdGltaXppbmcgZm9yIGludGVyb3BlcmFiaWxp
dHkgYW5kIG1pbmltaXppbmcgdGhlIGJ1cmRlbiBvbiBkZXZlbG9wZXJzIGlzIGFic29sdXRlbHkg
YSBnb29kIGdvYWwsIGFuZCByZXF1aXJpbmcgUEtDRSBpcyBhIGdyZWF0IHdheSB0byBhY2NvbXBs
aXNoIHRoYXQuIE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIHRo
YXQgZG9uJ3Qgc3VwcG9ydCBQS0NFIHdpbGwgY29udGludWUNCiB0byB3b3JrIGFzIHRoZXkgY3Vy
cmVudGx5IGRvLCB0aGV5IGp1c3Qgd29uJ3QgYmUgYWJsZSB0byBjYWxsIHRoZW1zZWx2ZXMgT0F1
dGggMi4xIGNvbXBsaWFudCwganVzdCBhcyBpcyB0aGUgY2FzZSBhcyBpZiB0aGV5IGRvbid0IGZv
bGxvdyB0aGUgb3RoZXIgcmVjb21tZW5kYXRpb25zIHRoYXQgYXJlIGluIE9BdXRoIDIuMSBhbmQg
dGhlIFNlY3VyaXR5IEJDUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+QWFyb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1heSA3LCAyMDIwIGF0IDY6NDIgUE0g
TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BYXJvbiwg
SSBiZWxpZXZlIHlvdeKAmXJlIHRyeWluZyB0byBvcHRpbWl6ZSB0aGUgd3JvbmcgdGhpbmcuJm5i
c3A7IFlvdeKAmXJlIGNvbmNlcm5lZCBhYm91dCDigJw8L3NwYW4+dGhlIGFtb3VudCBvZiBleHBs
YW5hdGlvbiB0aGlzIHdpbGwgdGFrZTxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7igJ0uJm5i
c3A7DQogVGhhdOKAmXMgb3B0aW1pemluZyBmb3Igc3BlYyBzaW1wbGljaXR5IOKAkyBhIGdvYWwg
dGhhdCBJIGRvIHVuZGVyc3RhbmQuJm5ic3A7IEhvd2V2ZXIsIGJ5IHdyaXRpbmcgdGhlc2UgZmV3
IHNlbnRlbmNlcyBvciBwYXJhZ3JhcGhzLCB3ZeKAmWxsIG1ha2UgaXQgY2xlYXIgdG8gZGV2ZWxv
cGVycyB0aGF0IGh1bmRyZWRzIG9yIHRob3VzYW5kcyBvZiBkZXBsb3llZCBPcGVuSUQgQ29ubmVj
dCBSUHMgd29u4oCZdCBoYXZlIHRvIGNoYW5nZSB0aGVpciBkZXBsb3ltZW50cy4mbmJzcDsNCiBU
aGF04oCZcyBvcHRpbWl6aW5nIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBtaW5pbWl6aW5nIHRo
ZSBidXJkZW4gb24gZGV2ZWxvcGVycywgd2hpY2ggYXJlIGZhciBtb3JlIGltcG9ydGFudC48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj
b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BcyBCcmlhbiBDYW1wYmVsbCB3
cm90ZSwg4oCcPC9zcGFuPlRoZXkgYXJlIG5vdCBlcXVpdmFsZW50IGFuZCBoYXZlIHZlcnkgZGlm
ZmVyZW50IHJhbWlmaWNhdGlvbnMgb24gaW50ZXJvcGVyYWJpbGl0eTxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj7igJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
RXZlbiBpZiB5b3XigJlyZSBvcHRpbWl6aW5nIGZvciB3cml0aW5nLCB0YWtpbmcgYSBtaW5pbWFs
bHkgaW52YXNpdmUgcHJvdG9jb2wgY2hhbmdlIGFwcHJvYWNoIHdpbGwgb3B0aW1pemUgdGhhdCwg
b3ZlcmFsbC4mbmJzcDsgSWYgd2UgcHJvY2VlZCBhcyB5b3XigJlyZSBzdWdnZXN0aW5nLA0KIGEg
aHVnZSBhbW91bnQgb2Ygd3JpdGluZyB3aWxsIG9jY3VyIG9uIFN0YWNrT3ZlcmZsb3csIE1lZGl1
bSwgU2xhc2hEb3QsIGJsb2dzLCBhbmQgb3RoZXIgZGV2ZWxvcGVyIGZvcnVtcywgd2hlcmUgY29u
ZnVzZWQgZGV2ZWxvcGVycyB3aWxsIGFzayDigJxXaHkgZG8gSSBoYXZlIHRvIGNoYW5nZSBteSBk
ZXBsb3llZCBjb2RlP+KAnSB3aXRoIHRoZSBhbnN3ZXJzIGJlaW5nIOKAnERlc3BpdGUgd2hhdCB0
aGUgMi4xIHNwZWMgc2F5cywgdGhlcmXigJlzIG5vIG5lZWQNCiB0byBjaGFuZ2UgeW91ciBkZXBs
b3llZCBjb2RlLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkni
gJlkIGdsYWRseSB3cml0ZSBhIGZldyBzZW50ZW5jZXMgaW4gb3VyIG5ldyBzcGVjcyBub3cgdG8g
cHJldmVudCBvbmdvaW5nIGNvbmZ1c2lvbiBhbmQgaW50ZXJvcCBwcm9ibGVtcyB0aGF0IHdvdWxk
IG90aGVyd2lzZSByZXN1bHQuJm5ic3A7IExldCBtZSBrbm93IHdoZW4NCiB5b3XigJlyZSByZWFk
eSB0byBpbmNvcnBvcmF0ZSB0aGVtIGludG8gdGhlIHNwZWMgdGV4dC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGI+RnJvbTo8L2I+IEFhcm9uIFBhcmVja2kgJmx0OzxhIGhyZWY9Im1haWx0bzphYXJvbkBwYXJl
Y2tpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFhcm9uQHBhcmVja2kuY29tPC9hPiZndDsNCjxicj4N
CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDcsIDIwMjAgNDozOSBQTTxicj4NCjxiPlRvOjwv
Yj4gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0
YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv
Yj4gT0F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0Ozxh
IGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRv
cnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDs7IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1h
aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVs
LkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogT0F1
dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUncyBhbm90aGVy
IHBvaW50IGhlcmUgdGhhdCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVzZSBkaXNjdXNz
aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Q
S0NFIHNvbHZlcyB0d28gcHJvYmxlbXM6IHN0b2xlbiBhdXRob3JpemF0aW9uIGNvZGVzIGZvciBw
dWJsaWMgY2xpZW50cywgYW5kIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gZm9yIGFsbCBj
bGllbnRzLiBXZSd2ZSBvbmx5IGJlZW4gdGFsa2luZyBhYm91dCBhdXRob3JpemF0aW9uIGNvZGUg
aW5qZWN0aW9uDQogb24gdGhlIGxpc3Qgc28gZmFyLiBUaGUgcXVvdGVkIHNlY3Rpb24gb2YgdGhl
IHNlY3VyaXR5IEJDUCAoNC41LjMpIHdoaWNoIHNheXMgY2xpZW50cyBjYW4gZG8gUEtDRSBvciB1
c2UgdGhlIG5vbmNlLCBpcyBvbmx5IHRhbGtpbmcgYWJvdXQgcHJldmVudGluZyBhdXRob3JpemF0
aW9uIGNvZGUgaW5qZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG5vbmNlIHBhcmFtZXRlciBzb2x2ZXMgYXV0aG9yaXph
dGlvbiBjb2RlIGluamVjdGlvbiBpZiB0aGUgY2xpZW50IHJlcXVlc3RzIGFuIElEIHRva2VuLiBQ
dWJsaWMgY2xpZW50cyB1c2luZyB0aGUgbm9uY2UgcGFyYW1ldGVyIGFyZSBzdGlsbCBzdXNjZXB0
aWJsZSB0byBzdG9sZW4gYXV0aG9yaXphdGlvbg0KIGNvZGVzIHNvIHRoZXkgc3RpbGwgbmVlZCB0
byBkbyBQS0NFIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5UaGUgb25seSBjYXNlIHdoZXJlIE9wZW5JRCBDb25uZWN0IGNs
aWVudHMgZG9uJ3QgYmVuZWZpdCBmcm9tIFBLQ0UgaXMgaWYgdGhleSBhcmUgYWxzbyBjb25maWRl
bnRpYWwgY2xpZW50cy4gUHVibGljIGNsaWVudCBPSURDIGNsaWVudHMgc3RpbGwgbmVlZCB0byBk
byBQS0NFIGV2ZW4gaWYgdGhleSBjaGVjaw0KIHRoZSBub25jZS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9wZW5JRCBDb25uZWN0IHNl
cnZlcnMgd29ya2luZyB3aXRoIGNvbmZpZGVudGlhbCBjbGllbnRzIHN0aWxsIGJlbmVmaXQgZnJv
bSBQS0NFIGJlY2F1c2UgdGhleSBjYW4gdGhlbiBlbmZvcmNlIHRoZSBhdXRob3JpemF0aW9uIGNv
ZGUgaW5qZWN0aW9uIHByb3RlY3Rpb24gc2VydmVyLXNpZGUmbmJzcDtyYXRoZXImbmJzcDt0aGFu
DQogY3Jvc3MgdGhlaXIgZmluZ2VycyB0aGF0IGNsaWVudHMgaW1wbGVtZW50ZWQgdGhlIG5vbmNl
IGNoZWNrIHByb3Blcmx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+SSByZWFsbHkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0aCB0aGUgYW1v
dW50IG9mIGV4cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtlIGluIHRoZSBmdXR1cmUgdG8gd3JpdGUg
YW4gZXhjZXB0aW9uIGludG8gT0F1dGggMi4xIG9yIHRoZSBTZWN1cml0eSBCQ1AgZm9yIG9ubHkg
c29tZSB0eXBlcyBvZiBPcGVuSUQgQ29ubmVjdA0KIGNsaWVudHMgd2hlbiBhbGwgY2xpZW50cyB3
b3VsZCBiZW5lZml0IGZyb20gUEtDRSBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BYXJvbjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIE1h
eSA2LCAyMDIwIGF0IDEwOjQ4IEFNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr
LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln
aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkhlbGxvITxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPldlIHdvdWxkIGxpa2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAy
LjEgY29kZSBmbG93cy4gVGhpcyBpcyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlz
IG5vdCBjb21tb24gaW4gT3BlbklEIENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVz
IHNvbWUgb2YgdGhlIGlzc3Vlcw0KIHRoYXQgUEtDRSBwcm90ZWN0cyBhZ2FpbnN0LiBXZSB0aGlu
ayB0aGF0IG1vc3QgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBP
QXV0aCAyLjAsIGFuZCBoZW5jZSZuYnNwO2hhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dp
bmcgYmVzdCBwcmFjdGljZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5UaGUgYWR2YW50YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4tIGEgc2ltcGxlciBwcm9ncmFtbWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0
aW9ucyBhbmQgcHJvZmlsZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0U8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gcmVkdWNlZCBhdHRhY2sg
c3VyZmFjZSB3aGVuIHVzaW5nJm5ic3A7IFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVy
aWZpZXIgaXMgc2VudCB0aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRl
eHQgdmFsdWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPi0gZW5mb3JjZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2ll
ciB0byBoYW5kbGUgZm9yIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBj
aGVjayBpcyBjb25kdWN0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPldoYXQgYXJlIGRpc2FkdmFudGFnZXMgYmVzaWRlcyB0aGUgcG90
ZW50aWFsIGltcGFjdCB0byBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cz8gSG93IHNpZ25pZmlj
YW50IGlzIHRoYXQgaW1wYWN0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+RGljaywgQWFyb24sIGFuZCBUb3JzdGVuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDou
MDEwNGluO2hlaWdodDouMDEwNGluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFp
bGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIw
JTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5
LWIyODQ3NDRiYzE3MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom
cXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_DM6PR00MB06824211CEC46217264F4F60F5A30DM6PR00MB0682namp_--


From nobody Sat May  9 17:52:01 2020
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 9662C3A0CB9; Sat,  9 May 2020 17:51:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.129.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <158907186941.32364.3855329773244277548@ietfa.amsl.com>
Date: Sat, 09 May 2020 17:51:09 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-22.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 00:51:10 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-22.txt
	Pages           : 32
	Date            : 2020-05-07

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-22
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-22


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 Sun May 10 03:15:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A7A3A0870 for ; Sun, 10 May 2020 03:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnlpHVKwIMf3 for ; Sun, 10 May 2020 03:15:17 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCEE3A086D for ; Sun, 10 May 2020 03:15:17 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id x6so3812190vso.1 for ; Sun, 10 May 2020 03:15:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eQ3N5ZDKTUZhWd7sW/9P26PAe9BB7+QOUy3Sd2kcP4I=; b=PeNiJDG94hMByLU+mqB4gIgiVPSngjYu0a5I5F9iFRLjuvVJUXh3PQ9b6p+WTT587D j6mN5hG8ckVauJT2bsGcJnFUw7Rkw+9c4gN24o1Z8VAUWHfCAJPzOeMdxEMPoVGHE9WU e808gqi7ppu7Ipr5u+pM2hF3h8VI/brZk3YtFqruHDJJLZ+I5jTUwAsdlRbvI+IgigaF sm9YIR2/Sp4LBfxmFJO0nFdJ5TriKJSyIu/zqmgQFSHdurL2ZOKIH/GJfz+KCyJkN/A4 WGPvvzuI75ZmJudokJ+pjwZtw6DSffTONf1nBC2xtC1iKwKLY+XO2/thWTGc2HXj0rpr Nm5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eQ3N5ZDKTUZhWd7sW/9P26PAe9BB7+QOUy3Sd2kcP4I=; b=r5bfWdVVU/S6D1p1VhH1w+sbCal41mZlnMk7DwtaSpPRY+gOlh6bQtPk87lcMOWOZx I9aI0g2qYmD0KzvObAVoyoyufbkXC+WwhcHy0Hbte/dOCs3hzT8RjrbJDTa7ivt51OBr F/LONZAW+lp6ljD8f+I5nlhlHXG6yT6FIOX+PH/1O/IV83MgY5KTDdceVo6fUBgn3FqI KSrLwLyC4Fr5yR/mRqyNZR3Gdhv0MEbd5KtQRmQGxpi0FIKHJw4B3Kx+FaiwVkpfvqzs AoG6cHzuX5iHNAjho81H3LdxA1u4s/95xBriVwNbBCKJh3Fi5EXkFgTcXPPj8kYj0fpE wC9Q==
X-Gm-Message-State: AGi0PuZjmKuM1sr7D6H0afTc9CbMAk0ZXhdCbKk1R+fOkrZs62sSw6mi pkSeZabRvBQhZLdXu+7OJYluMoiUOLyA3fJYaHldMRpT
X-Google-Smtp-Source: APiQypJZdY4gxWqjNE2ak5bUo5vG3IxHjvGaetZid4XpC7ihgmzjL7IfOrKaCRmladyJ/MS7QdDiKkCfiv1X1BHQ9/c=
X-Received: by 2002:a67:6889:: with SMTP id d131mr7763085vsc.25.1589105716358;  Sun, 10 May 2020 03:15:16 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Torsten Lodderstedt 
Date: Sun, 10 May 2020 12:15:05 +0200
Message-ID: 
To: Mike Jones 
Cc: Daniel Fett , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000bc041505a5488162"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 10:15:22 -0000

--000000000000bc041505a5488162
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mike,

Mike Jones  schrieb am Fr. =
8.
Mai 2020 um 18:55:

> OAuth 2.1 was supposed to not introduce breaking changes.
>
I cannot remember the WG met that decision. Can you please refer to the
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you
oppose against this as well?


If you want to do that, please do it in TxAuth instead.
>

Interesting statement. Does it mean you want to conserve OAuth 2.0 and
force any enhancements/improvements to go into TXAuth? This would cause
huge migration efforts for existing deployments wanting to benefit from
those enhancements.

I think existing deployments are better served by actively maintaining and
evolving the 2.x line. For example, PAR and RAR are attempts to improve
OAuth 2.x and make it usable for new use cases. That=E2=80=99s better prote=
ction of
existing investments than sending them of to TXAuth.

> Kind regards,
Torsten.


>
>                                                        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Daniel Fett
> *Sent:* Thursday, May 7, 2020 11:50 PM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> +1 to all what Aaron said. Thanks for pointing this out!
>
>
>
> We need to address this in the security BCP and this will be a normative
> change that affects OpenID Connect Core (just as our current recommendati=
on
> on the usage of nonce).
>
>
>
> We would then have:
>
>
>
> - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE=
,
> except if you are a public client, then you still need PKCE.
>
> - use state, except if you use PKCE, then you don't need state.
>
>
>
> I think there are very good reasons to simplify this down to
>
>
>
> - use PKCE
>
> - you may or may not use state
>
>
>
> First and foremost, not many people will understand why there are cases
> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
> understanding *why* you have to do something is key to compliance. The
> short version "PKCE protects the code; there is a specific case where it =
is
> not needed, but its better to use it all the time" is easy to understand.
> We will not see many implementations following the long version above
> correctly.
>
>
>
> Second, we dramatically reduce technical complexity by reducing cases tha=
t
> need to be handled. We reduce correctness and compliance testing complexi=
ty
> in the same way. We reduce the cost of security analysis, which scales
> really badly to more cases.
>
>
>
> And finally, using nonce to protect against code injection is less robust
> than PKCE. AS have a better track record than clients when it comes to
> correctly implementing security mechanisms.
>
>
>
> Yes, this will make a number of implementations non-spec-compliant, but I
> do not think that this is a huge problem. Software needs to adapt all the
> time and a software that has not been changed in a while is probably not
> one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will g=
et
> there.
>
>
>
> -Daniel
>
>
>
>
>
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>
> Backing up a step or two, there's another point here that I think has bee=
n
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE a=
s
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP fo=
r
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000bc041505a5488162
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Mike,

Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.=
org> schrieb am Fr. 8. Mai 2020 um 18:55:


OAuth 2.1 was supposed=
 to not introduce breaking changes.=C2=A0
I cannot remember the WG met that decision. Can you ple=
ase refer to the respective thread?=C2=A0

=

Requiring exact redirect URI matching is already a breaki=
ng change. Do you oppose against this as well?

<=
/div>

 If yo=
u want to do that, please do it in TxAuth instead.

Interesting statem=
ent. Does it mean you want to conserve OAuth 2.0 and force any enhancements=
/improvements to go into TXAuth? This would cause huge migration efforts fo=
r existing deployments wanting to benefit from those enhancements.

I think existing deployments are=
 better served by actively maintaining and evolving the 2.x line. For examp=
le, PAR and RAR are attempts to improve OAuth 2.x and make it usable for ne=
w use cases. That=E2=80=99s better protection of existing investments than =
sending them of to TXAuth.
Kind regards,
Torsten.



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=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 <oauth-bounces@ietf.org> On Behalf =
Of 
Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?






=C2=A0




+1 to all what Aaron said. Thanks for pointing this =
out!






=C2=A0






We need to address this in the security BCP and this=
 will be a normative change that affects OpenID Connect Core (just as our c=
urrent recommendation on the usage of nonce).






=C2=A0






We would then have:






=C2=A0






- use PKCE, except if you use OIDC with a nonce, the=
n you don't need PKCE, except if you are a public client, then you stil=
l need PKCE.






- use state, except if you use PKCE, then you don=
9;t need state.






=C2=A0






I think there are very good reasons to simplify this=
 down to







=C2=A0






- use PKCE






- you may or may not use state






=C2=A0






First and foremost, not many people will understand =
why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where they=
 don't. However, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.






=C2=A0






Second, we dramatically reduce technical complexity =
by reducing cases that need to be handled. We reduce correctness and compli=
ance testing complexity in the same way. We reduce the cost of security ana=
lysis, which scales really badly to
 more cases.






=C2=A0






And finally, using nonce to protect against code inj=
ection is less robust than PKCE. AS have a better track record than clients=
 when it comes to correctly implementing security mechanisms.







=C2=A0






Yes, this will make a number of implementations non-=
spec-compliant, but I do not think that this is a huge problem. Software ne=
eds to adapt all the time and a software that has not been changed in a whi=
le is probably not one you would want
 to use anyway. We are setting a new goal for implementations to meet and e=
ventually, maintained implementations will get there.






=C2=A0






-Daniel






=C2=A0






=C2=A0






Am 08.05.20 um 01:38 schrieb Aaron Parecki:










Backing up a step or two, there's another point =
here that I think has been missed in these discussions.





=C2=A0






PKCE solves two problems: stolen authorization codes=
 for public clients, and authorization code injection for all clients. We&#=
39;ve only been talking about authorization code injection on the list so f=
ar. The quoted section of the security
 BCP (4.5.3) which says clients can do PKCE or use the nonce, is only talki=
ng about preventing authorization code injection.






=C2=A0






The nonce parameter solves authorization code inject=
ion if the client requests an ID token. Public clients using the nonce para=
meter are still susceptible to stolen authorization codes so they still nee=
d to do PKCE as well.






=C2=A0






The only case where OpenID Connect clients don't=
 benefit from PKCE is if they are also confidential clients. Public client =
OIDC clients still need to do PKCE even if they check the nonce.<=
/u>






=C2=A0






OpenID Connect servers working with confidential cli=
ents still benefit from PKCE because they can then enforce the authorizatio=
n code injection protection server-side=C2=A0rather=C2=A0than cross their f=
ingers that clients implemented the nonce check
 properly.






=C2=A0






I really don't think it's worth the amount o=
f explanation this will take in the future to write an exception into OAuth=
 2.1 or the Security BCP for only some types of OpenID Connect clients when=
 all clients would benefit from PKCE anyway.






=C2=A0






Aaron






=C2=A0








=C2=A0




=C2=A0






On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:










Hello! 




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues that PKCE protects ag=
ainst. We think that most OpenID Connect
 implementations also support OAuth 2.0, and hence=C2=A0have support for PK=
CE if following best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=
=E1=90=A7

















_______________________________________________


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/listinfo/oauth




--000000000000bc041505a5488162--


From nobody Sun May 10 03:17:35 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AA33A0876 for ; Sun, 10 May 2020 03:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0d0BZlUoUsx for ; Sun, 10 May 2020 03:17:26 -0700 (PDT)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752543A0872 for ; Sun, 10 May 2020 03:17:25 -0700 (PDT)
Received: by mail-ua1-x932.google.com with SMTP id r2so2314848uam.7 for ; Sun, 10 May 2020 03:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3TOqKFn0vPZIRA1iCkBbD8DhGVOSJjLRbmNVi/WC88E=; b=NGV7Exu8YVyvjD2ZV2Ym9vIhFENQjwAWOPp7vbTCD8SAuZIB787cAZtvw+nSfkm+zD F13Dut4p/wz1LTjuHE2GLYQZyrH8OLkvHDLIFNHgrI6E7yf99iq2b3KTgufNu+tr44nu fPEuit9DL6fcHGxnBqg7hUE8GhTM+049I/8wt6Kq7VBPJoW1iyQvNXfYTNgwobaFKxo7 kDqri9GLRi6MLtSLU5H41K9+4PnnxkuB11PCX0mlJrnaxcJhf4tkdTlmNBqNHz0WqXCy bMGXEBp95+67jmu25kq/+CHNXu8BKPGhOAizL8jYbsciPDABb5ZmCq1jABKXuceCZv0f JhuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3TOqKFn0vPZIRA1iCkBbD8DhGVOSJjLRbmNVi/WC88E=; b=V0Vvnjclyh8sSSAIi0NE+iwTCr1y5k6REICHK6Z/yaMEVwtW5gRNBkU0VLxK4wtnVN Enq2vYjpgWLcwUEm/V6jPBmPgUSISm6TcvovknY94Dlg3M5nszJ8uZlrnJ+Lq011Fn8H /DMqK1GCOrcQbJhQhFYlJqVf/h1QSKMQx0/VHwBB1OSJFxqxGaq8I/4py2uhQoncOknH ha3hqM33WArtP9R1rwJFpmkcKDd8HvH5No137bqJIxp8TkC6velb/DmzNL1ZMFH+WU4v j1f0ZabXNOV1bFWQlWCHDDt3PFMncn5FhYRhM9qewgQn0/c5GMumML8vU9yooHM0N82s 2tTA==
X-Gm-Message-State: AGi0Puac4aOxLvo8mwhK0WuH0UPHtfrghFR5qswpzKweF130SF2OcAoR Jwrdx1IyNqc9cKKviDCN22nlWunocJkXCkHef5BByQ==
X-Google-Smtp-Source: APiQypIOSJyLY0LXhNVOO4R4YGeAQjHIbasEGKWP5UkBgjGzYvxawACdyYP9MqoN3dRt8o5P0RjgdQZX4S6ccarIw2k=
X-Received: by 2002:ab0:7481:: with SMTP id n1mr7729927uap.89.1589105844295; Sun, 10 May 2020 03:17:24 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Torsten Lodderstedt 
Date: Sun, 10 May 2020 12:17:13 +0200
Message-ID: 
To: Mike Jones 
Cc: Aaron Parecki , Dick Hardt , OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000005c312b05a5488934"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 10:17:32 -0000

--0000000000005c312b05a5488934
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Mike Jones  schrieb am Sa. 9. Mai 2020 um
20:46:

> There=E2=80=99s a huge ecosystem of successful, secure OAuth 2.0 and Open=
ID
> Connect deployments that we have the responsibility to be stewards of.
> This working group should be proud of what it=E2=80=99s accomplished.  Pa=
rt of good
> stewardship is not unnecessarily bifurcating the ecosystem into
> non-interoperable segments.  OAuth 2.1 should facilitate the already secu=
re
> OAuth 2.0 deployments remaining part of the interoperable OAuth 2.1 set o=
f
> deployments =E2=80=93 not intentionally doing the opposite.
>
>
>
> If it ain=E2=80=99t broke, don=E2=80=99t fix it!
>
Did I got it right that nonce does not protect public clients from code
theft/replay? I would consider this a security issue.

>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Friday, May 8, 2020 8:34 PM
> *To:* OAuth WG 
> *Cc:* Dick Hardt ; Torsten Lodderstedt <
> torsten@lodderstedt.net>; Mike Jones 
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
>
>
> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  You=
=E2=80=99re
> concerned about =E2=80=9Cthe amount of explanation this will take=E2=80=
=9D.  That=E2=80=99s
> optimizing for spec simplicity =E2=80=93 a goal that I do understand.  Ho=
wever, by
> writing these few sentences or paragraphs, we=E2=80=99ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won=
=E2=80=99t
> have to change their deployments.  That=E2=80=99s optimizing for interope=
rability
> and minimizing the burden on developers, which are far more important.
>
>
>
> I appreciate the concern about optimizing for spec simplicity. I also
> agree that spec simplicity should not necessarily be the driving goal.
>
>
>
> However, what you've described is the opposite of interoperability and
> minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without
> any exceptions, will optimize for interoperability between OAuth 2.1
> clients and servers. Without the requirement of PKCE, there will always b=
e
> the question of "but does this OAuth 2.1 client work with this OAuth 2.1
> server or not?", which will only be able to be answered by investigating
> the docs to look for PKCE support, or by checking the AS metadata documen=
t
> if it publishes one (which it is not required to do).
>
>
>
> Optimizing for interoperability and minimizing the burden on developers i=
s
> absolutely a good goal, and requiring PKCE is a great way to accomplish
> that. OAuth 2.0 and OpenID Connect implementations that don't support PKC=
E
> will continue to work as they currently do, they just won't be able to ca=
ll
> themselves OAuth 2.1 compliant, just as is the case as if they don't foll=
ow
> the other recommendations that are in OAuth 2.1 and the Security BCP.
>
>
>
> Aaron
>
>
>
>
>
> On Thu, May 7, 2020 at 6:42 PM Mike Jones 
> wrote:
>
> Aaron, I believe you=E2=80=99re trying to optimize the wrong thing.  You=
=E2=80=99re
> concerned about =E2=80=9Cthe amount of explanation this will take=E2=80=
=9D.  That=E2=80=99s
> optimizing for spec simplicity =E2=80=93 a goal that I do understand.  Ho=
wever, by
> writing these few sentences or paragraphs, we=E2=80=99ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won=
=E2=80=99t
> have to change their deployments.  That=E2=80=99s optimizing for interope=
rability
> and minimizing the burden on developers, which are far more important.
>
>
>
> As Brian Campbell wrote, =E2=80=9CThey are not equivalent and have very d=
ifferent
> ramifications on interoperability=E2=80=9D.
>
>
>
> Even if you=E2=80=99re optimizing for writing, taking a minimally invasiv=
e
> protocol change approach will optimize that, overall.  If we proceed as
> you=E2=80=99re suggesting, a huge amount of writing will occur on StackOv=
erflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask =E2=80=9CWhy do I have to change my deployed code?=E2=
=80=9D with the
> answers being =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99s no=
 need to change
> your deployed code.=E2=80=9D
>
>
>
> I=E2=80=99d gladly write a few sentences in our new specs now to prevent =
ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you=E2=80=99re ready to incorporate them into the spec text.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt 
> *Cc:* OAuth WG ; Torsten Lodderstedt <
> torsten@lodderstedt.net>; Mike Jones 
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
>
>
> Backing up a step or two, there's another point here that I think has bee=
n
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE a=
s
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP fo=
r
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
>

--0000000000005c312b05a5488934
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




Mike Jones <Michael.Jones@microsoft.com> schrieb am Sa. 9. Mai 2020 um 20:46:=












There=E2=80=99s a huge=
 ecosystem of successful, secure OAuth 2.0 and OpenID Connect deployments t=
hat we have the responsibility to be stewards of.=C2=A0 This working group =
should be proud of what it=E2=80=99s accomplished.=C2=A0 Part
 of good stewardship is not unnecessarily bifurcating the ecosystem into no=
n-interoperable segments.=C2=A0 OAuth 2.1 should facilitate the already sec=
ure OAuth 2.0 deployments remaining part of the interoperable OAuth 2.1 set=
 of deployments =E2=80=93 not intentionally doing
 the opposite.


=C2=A0


If it ain=E2=80=99t br=
oke, don=E2=80=99t fix it!
Did I got it right that nonce does not protect public clients from cod=
e theft/replay? I would consider this a security issue.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=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: Aaron Parecki <aaron@parecki.com> 

Sent: Friday, May 8, 2020 8:34 PM

To: OAuth WG <oauth@ietf.org>

Cc: Dick Hardt <dick.hardt@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net>; Mike Jones <Michael.Jones@microsoft.com>

Subject: Re: OAuth 2.1 - require PKCE?




=C2=A0






Aaron, I believe you=E2=80=99re trying to optimize t=
he wrong thing.=C2=A0 You=E2=80=99re concerned about =E2=80=9Cthe amount of=
 explanation this will take=E2=80=9D.=C2=A0 That=E2=80=99s optimizing for s=
pec simplicity =E2=80=93 a goal that I do understand.=C2=A0 However, by wri=
ting these few sentences
 or paragraphs, we=E2=80=99ll make it clear to developers that hundreds or =
thousands of deployed OpenID Connect RPs won=E2=80=99t have to change their=
 deployments.=C2=A0 That=E2=80=99s optimizing for interoperability and mini=
mizing the burden on developers, which are far more important.






=C2=A0






I appreciate the concern about optimizing for spec s=
implicity. I also agree that spec simplicity should not necessarily be the =
driving goal.






=C2=A0






However, what you've described is the opposite o=
f interoperability and minimizing the burden on developers. Requiring PKCE =
in OAuth 2.1, without any exceptions, will optimize for interoperability be=
tween OAuth 2.1 clients and servers. Without
 the requirement of PKCE, there will always be the question of "but do=
es this OAuth 2.1 client work with this OAuth 2.1 server or not?", whi=
ch will only be able to be answered by investigating the docs to look for P=
KCE support, or by checking the AS metadata
 document if it publishes one (which it is not required to do).






=C2=A0






Optimizing for interoperability and minimizing the b=
urden on developers is absolutely a good goal, and requiring PKCE is a grea=
t way to accomplish that. OAuth 2.0 and OpenID Connect implementations that=
 don't support PKCE will continue
 to work as they currently do, they just won't be able to call themselv=
es OAuth 2.1 compliant, just as is the case as if they don't follow the=
 other recommendations that are in OAuth 2.1 and the Security BCP.






=C2=A0






Aaron=C2=A0






=C2=A0






=C2=A0






On Thu, May 7, 2020 at 6:42 PM Mike Jones <Michael.Jones@mi=
crosoft.com> wrote:










Aaron, I believe you=
=E2=80=99re trying to optimize the wrong thing.=C2=A0 You=E2=80=99re concer=
ned about =E2=80=9Cthe amount of explanation this will take=E2=80=9D.=C2=A0
 That=E2=80=99s optimizing for spec simplicity =E2=80=93 a goal that I do u=
nderstand.=C2=A0 However, by writing these few sentences or paragraphs, we=
=E2=80=99ll make it clear to developers that hundreds or thousands of deplo=
yed OpenID Connect RPs won=E2=80=99t have to change their deployments.=C2=
=A0
 That=E2=80=99s optimizing for interoperability and minimizing the burden o=
n developers, which are far more important.


=C2=A0


As Brian Campbell wrot=
e, =E2=80=9CThey are not equivalent and have very different ramifica=
tions on interoperability=E2=80=9D.=



=C2=A0


Even if you=E2=80=99re=
 optimizing for writing, taking a minimally invasive protocol change approa=
ch will optimize that, overall.=C2=A0 If we proceed as you=E2=80=99re sugge=
sting,
 a huge amount of writing will occur on StackOverflow, Medium, SlashDot, bl=
ogs, and other developer forums, where confused developers will ask =E2=80=
=9CWhy do I have to change my deployed code?=E2=80=9D with the answers bein=
g =E2=80=9CDespite what the 2.1 spec says, there=E2=80=99s no need
 to change your deployed code.=E2=80=9D


=C2=A0


I=E2=80=99d gladly wri=
te a few sentences in our new specs now to prevent ongoing confusion and in=
terop problems that would otherwise result.=C2=A0 Let me know when
 you=E2=80=99re ready to incorporate them into the spec text.=



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=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: Aaron Parecki <aaron@parecki.com>


Sent: Thursday, May 7, 2020 4:39 PM

To: Dick Hardt <dick.hardt@gmail.com>

Cc: OAuth WG <oauth@ietf.org>; Torsten Lodderstedt <torsten@lodderstedt.net>; Mike Jo=
nes <Mi=
chael.Jones@microsoft.com>

Subject: Re: OAuth 2.1 - require PKCE?




=C2=A0






Backing up a step or two, there's another point =
here that I think has been missed in these discussions.




=C2=A0






PKCE solves two problems: stolen authorization codes=
 for public clients, and authorization code injection for all clients. We&#=
39;ve only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.






=C2=A0






The nonce parameter solves authorization code inject=
ion if the client requests an ID token. Public clients using the nonce para=
meter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.






=C2=A0






The only case where OpenID Connect clients don't=
 benefit from PKCE is if they are also confidential clients. Public client =
OIDC clients still need to do PKCE even if they check
 the nonce.






=C2=A0






OpenID Connect servers working with confidential cli=
ents still benefit from PKCE because they can then enforce the authorizatio=
n code injection protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.<=
/u>






=C2=A0






I really don't think it's worth the amount o=
f explanation this will take in the future to write an exception into OAuth=
 2.1 or the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.






=C2=A0






Aaron






=C2=A0








=C2=A0




=C2=A0






On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:










Hello!




=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=
=E1=90=A7

























--0000000000005c312b05a5488934--


From beenapurushothaman@gmail.com  Sun May 10 03:03:36 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEF73A0860 for ; Sun, 10 May 2020 03:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plkTc-FPkqzV for ; Sun, 10 May 2020 03:03:33 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4393A085D for ; Sun, 10 May 2020 03:03:32 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id 59so3124427qva.13 for ; Sun, 10 May 2020 03:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=cnq0h3GoA/3OFlTVMNdHUEmCSNoV/56RRTz1H+qLtBM=; b=ml4opn2L+qML7IfVVre2ihxaR5/nbSXiczzouZc/NWSGmAARg0Es6NGngC5XK6cZH8 AoT8sZCYLlE4+fUasO6fTc0sd2EV8z27rr3JgpcEwWhCM5Dg6TB2jChs3Y6Rv0SVQB9j BBrmbbgOENDsAJqncwfckp0El5R9mcqkEWQICalL4ZmhjDxsb0Oc/0BeYZM62jN/x1mc dVnljKtwGNpDInMDe6jdNUOQelePuxywYykF2AI6mld2TbWe2ulytjaGHX3q/KMstrDD ZPupyPBKzpSFWHjVCxzkmIi4b09D5vtu/6Y1+x44u9gg4xmpDG/StGeox5O2PPhNDGPl Ra8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cnq0h3GoA/3OFlTVMNdHUEmCSNoV/56RRTz1H+qLtBM=; b=NlFa4h8VzAlHgAhOLA5qpMwDr3NXKlmr9nx+90E9oQNeJsaYi+orK2cp2qco5QWNKx mI0Cs8WncHm29H2b+jAn9uZ+L02osS4UeFwuZvTL00IPEEDxh5kG6iidB5Pn9hR6+w0w hk5d6A8v76QQE5kAWj82ukXw0L/EorwopTp/ZXqmr3TVOyug9tWRPh7Ci5PFs0MEoJoi ZyNc595Sw0rkDtrVXRMrN9UxtqgJ4Cxg1hucTuIK2I3eFVYlCD4l1FRVYz6+/fORjyPB 0HYxpXYg9Yucf5uyyS3KakrQNQzr6jpcGkZPuzqrmt4+6/XsNvo5HrWfa9Lgw8zXUTHZ X9pA==
X-Gm-Message-State: AGi0Pua/qn71g5N0KysW9xMPnAWw9nDWy1jzjDymeiaWUnXn2vM5HZI9 4JwSFaVvMwCOFpOKR919UwIKiVvt+fjj/KQVk7Zr8IrZLUY=
X-Google-Smtp-Source: APiQypJ6IZiuuNp8c5y2ytOdNyeh6Nh3BWrmAGF4YKqsk02AppDY5kJkUqH515rBD53hOhZdznZ2/d0UWsTXWxOHqRE=
X-Received: by 2002:ad4:40c7:: with SMTP id x7mr9933023qvp.7.1589105011718; Sun, 10 May 2020 03:03:31 -0700 (PDT)
MIME-Version: 1.0
From: Beena Santhosh 
Date: Sun, 10 May 2020 15:33:21 +0530
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bbfe5505a54857b2"
Archived-At: 
Subject: [OAUTH-WG] Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 10:18:02 -0000

--000000000000bbfe5505a54857b2
Content-Type: text/plain; charset="UTF-8"

Hi,


We have a product with client server architecture where our server manages
thousands of devices. Each device has a client-piece that talks to the
server over SOAP/REST. The client currently uses a HTTP Basic
Authentication (unique id and a secret string) for all the calls. The
secret string is created when the device enrolls to the server. It is
available at the server as well as stored securely on the device. For the
rest calls it is the device that is getting authenticated.



 Sending the credentials every time is less than ideal and we want to move
to some tokenized device authentication. We evaluated OpendID Connect based
on the general recommendation of SSO solution, but the issue is we do not
have any user interaction and hence there is no Grant flow that is fitting.
Hence we evaluated OAuth grant type of which we found Password Grant and
Client Credentials Grant is matching our requirement.



 In order to use Client Credentials in our use case, we need to do dynamic
registration for the thousands of devices managed by the server, if IoT
comes into picture the number is going to be even higher, which is highly
cumbersome to manage.  Also, as per  RFC7591 on dynamic client
registration, using access token for registering client is optional too.
Even though the Password grant is highly discouraged by the spec, we found
it to be highly matching with our requirements.



But as per the Oauth 2.1 proposal, password grant is going to be removed. Can
you suggest the way forward for us? I believe we are not a one-off case.


Thank You,

Beena

--000000000000bbfe5505a54857b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

=

We have a produc=
t
with client server architecture where our server manages thousands of devic=
es.
Each device has a client-piece that talks to the server over SOAP/REST. The
client currently uses a HTTP Basic Authentication (unique id and a secret
string) for all the calls. The secret string is created when the device enr=
olls
to the server. It is available at the server as well as stored securely on =
the
device. For the rest calls it is the device that is getting authenticated.<=
/p>


=C2=A0



=C2=A0Sending th=
e credentials every time is less
than ideal and we want to move to some tokenized device authentication. We
evaluated OpendID Connect based on the general recommendation of SSO soluti=
on,
but the issue is we do not have any user interaction and hence there is no
Grant flow that is fitting. Hence we evaluated OAuth grant type of which we
found Password Grant and Client Credentials Grant is matching our requireme=
nt.



=C2=A0



=C2=A0In order t=
o use Client Credentials in our use
case, we need to do dynamic registration for the thousands of devices manag=
ed
by the server, if IoT comes into picture the number is going to be even hig=
her,
which is highly cumbersome to manage.=C2=A0
Also, as per=C2=A0 RFC7591 on dynamic
client registration, using access token for registering client is optional
too.=C2=A0 Even though the Password grant is
highly discouraged by the spec, we found it to be highly matching with our
requirements.



=C2=A0



=
But as
per the Oauth 2.1 proposal, password grant is going to be removed. Can
you suggest the way forward for us? I
believe we are not a one-off case.

Thank You,<=
/span>
Beena


--000000000000bbfe5505a54857b2--


From nobody Sun May 10 06:26:14 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E423A097D for ; Sun, 10 May 2020 06:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNmVt6DStiUZ for ; Sun, 10 May 2020 06:26:08 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C0B3A097A for ; Sun, 10 May 2020 06:26:07 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id g12so15671236wmh.3 for ; Sun, 10 May 2020 06:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=l963xqZs5fnf/K8KmgRmTgphGXayUPyZdtIJGoqGYnI=; b=ikaX63w9wRC34XmCS24izyEFC5cLwR7mpZrYq4XZzO3XXHoQ9rJcJ27BaTItmHbziQ zuvycvmzSuYerEaSdAknK2Y0UBSZau/qehRpDbvxiU59O5xVVekNFCNokDnv8wd4GcOs BTGlqa3RCgnGlfUN+AnuNCRN8GDeG8a3v6KPb21UhIoUBy3+3HE9PLy9u4mICcaB4XNt pkJyUvJ6l9QXlGkZ6b3vuJwIV0fYxsGYzedAJZ90xHKm5vNSIDR5xT29WEnIybUDn9iI Y7b1SKotKOxW6udtykiucn6+tiV+8XCJwUTJmtNMQ+GYnyLLCddyUdYna5x+Z7Fgt2D9 xufg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=l963xqZs5fnf/K8KmgRmTgphGXayUPyZdtIJGoqGYnI=; b=tO4jTTJrdJE6p8wZLV1ee/b4J2ojXiEHSj8Hq+JBq643cvslTWUDAcY7dUzHWEgVq1 5oJYAB6BHMR4kAAibM7u4GBZKpC3fOBEZFgMqcH15lQ3+OHOvA1s/r0bQfqKMtd9nan2 uqbMZvQTYo6V4rI3nkwLiKqBPR1QhrZqg0TlXmfKcF9mWf+UvG32b79DoWie+Tai+b7b ASBAY2nNyFwRMjg9XgGtyYy+1F5YXiy4uGUa277bFE8J+hwxC+SJBIExNY+/pHxx5Eeu NWuphEZzmASEiPn9TAqW3wV3iNrAuOnKe5rYC0nHzpp3P3wXO2BIlTz8BHFOYqYp8tq0 HLAA==
X-Gm-Message-State: AGi0PubBOxl2oTtfwE05zTjy21jSNXEuTaaQabMg3y5GfpMApFS+CuYq bDSRKfYO3pYUOyl7/B6VktEp0WB6ZVw=
X-Google-Smtp-Source: APiQypIpHzw6VbOM4WOTttTUtu0J3cMcnOLh1PYwB9GTGihAeQ/q28EGsinstz6jb9lZZf9k/V7yUg==
X-Received: by 2002:a7b:c306:: with SMTP id k6mr25376406wmj.40.1589117165627;  Sun, 10 May 2020 06:26:05 -0700 (PDT)
Received: from p200300eb8f301f39e58c5bd211932ee5.dip0.t-ipconnect.de (p200300EB8F301F39E58C5BD211932EE5.dip0.t-ipconnect.de. [2003:eb:8f30:1f39:e58c:5bd2:1193:2ee5]) by smtp.gmail.com with ESMTPSA id n24sm6265859wmi.40.2020.05.10.06.26.04 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2020 06:26:04 -0700 (PDT)
From: Torsten Lodderstedt 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 10 May 2020 15:26:03 +0200
References: <158907186941.32364.3855329773244277548@ietfa.amsl.com>
To: oauth 
In-Reply-To: <158907186941.32364.3855329773244277548@ietfa.amsl.com>
Message-Id: <0F682743-D799-4773-A1E7-09701CEB2BD1@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-22.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 13:26:12 -0000

I just read over the diff between -21 and -22 and realised the example =
in Section 5.2.2.

https://server.example.com/authorize?
       response_type=3Dcode%20id_token
       &client_id=3Ds6BhdRkqt3
       &request_uri=3Dhttps%3A%2F%2Ftfp.example.org%2Frequest.jwt
       %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

 still has the =E2=80=9Cresponse_type" parameter. I think this parameter =
should be removed.=20



> On 10. May 2020, at 02:51, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Web Authorization Protocol WG of the =
IETF.
>=20
>        Title           : The OAuth 2.0 Authorization Framework: JWT =
Secured Authorization Request (JAR)
>        Authors         : Nat Sakimura
>                          John Bradley
> 	Filename        : draft-ietf-oauth-jwsreq-22.txt
> 	Pages           : 32
> 	Date            : 2020-05-07
>=20
> Abstract:
>   The authorization request in OAuth 2.0 described in RFC 6749 =
utilizes
>   query parameter serialization, which means that Authorization =
Request
>   parameters are encoded in the URI of the request and sent through
>   user agents such as web browsers.  While it is easy to implement, it
>   means that (a) the communication through the user agents are not
>   integrity protected and thus the parameters can be tainted, and (b)
>   the source of the communication is not authenticated.  Because of
>   these weaknesses, several attacks to the protocol have now been put
>   forward.
>=20
>   This document introduces the ability to send request parameters in a
>   JSON Web Token (JWT) instead, which allows the request to be signed
>   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>   (JWE) so that the integrity, source authentication and
>   confidentiality property of the Authorization Request is attained.
>   The request can be sent by value or by reference.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-22
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-22
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-22
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sun May 10 07:21:00 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7C63A09D2 for ; Sun, 10 May 2020 07:20:57 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BR6IguRMFYy for ; Sun, 10 May 2020 07:20:55 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31623A09D1 for ; Sun, 10 May 2020 07:20:53 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id u11so6779487iow.4 for ; Sun, 10 May 2020 07:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jRgCCz3zavzdc+Itnyd71jV0nEOpWwrpRE/hXzKoUnI=; b=1UIu4Mc6om+ojpZ9bfCtvXSso4gqPNlajZR5ZW1Gp4XI0bKiF0H2EhXF+4nMrd+Nbs o06Zfc/FE2S1+DLSbA1B3QfbJLvgUsMQKKdvGqlMltfXCT3ryaG0uW0469bH18iApft4 xIe6cha3HRofy2b35mTAOwFHXKn9Xny7YWJD3GE8jppR0ubaz9S0Ban4g/UTjM8ThFnv +c4Bh243DvG4eSJqFUs+NlXK/SIlb7TLhD3vT0jAczqzzfPq2O7UiXR7pOv8w4pEaa1l EMb8JVSsr7foHv0B3dSTtmo1Q+K7zNES9Z4qCcdYBApBawveP+WghteSNk7o1glgkBK4 QWZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jRgCCz3zavzdc+Itnyd71jV0nEOpWwrpRE/hXzKoUnI=; b=mLTFA1NfRJhh/w//iD5tuPuQrvj1rPDjBQ4RXjD4I0onaUpL0DJvx/QwhubwoawpkK C25nRR5wPRZYefKkjm+hl3C6JsrvCbCvLGJfPmOnzXGe5n5M4Za169RmPDoSnBRqI/Hj 55K9z6AoQ7IRxbl6birOXQeGp3D/2P9hBIdhkB5xo0p7JseVpUSNmd9rY+QjaNQa92Ai ZnxHnAUdy5Vy7S+J5C4BqWMprRyRUf39IWSAa2WYLS/08uptV3CexSPa0KxpzExi+jyC szJyX06ifIjWMUV4G2msuum4Bn4aje9x4jdu8FYJvdigzxVNBkvBemh/ySDYqapO5hR+ X1ug==
X-Gm-Message-State: AGi0PuZs+tfStz98TyMYY3AYp9lRacW22HEah3X3YHwUCH7A9Kkb5toU Syt84QcqXpPZboMZ8b3K/zO/P+TD0Pg=
X-Google-Smtp-Source: APiQypLHe++WSDHky6tifNtEvlM/fKzEgpn2Opl+XFnYlOvSBSfJV2zp53x3Zmn9mouWSWu7mkJuzQ==
X-Received: by 2002:a5d:8e0d:: with SMTP id e13mr11340735iod.132.1589120452406;  Sun, 10 May 2020 07:20:52 -0700 (PDT)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id u21sm3354622iot.5.2020.05.10.07.20.51 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 07:20:51 -0700 (PDT)
Received: by mail-io1-f41.google.com with SMTP id w11so6752563iov.8 for ; Sun, 10 May 2020 07:20:51 -0700 (PDT)
X-Received: by 2002:a05:6602:1303:: with SMTP id h3mr11127875iov.14.1589120450800;  Sun, 10 May 2020 07:20:50 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Sun, 10 May 2020 07:20:39 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Beena Santhosh 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000f9b2e605a54beff6"
Archived-At: 
Subject: Re: [OAUTH-WG] Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 14:20:59 -0000

--000000000000f9b2e605a54beff6
Content-Type: text/plain; charset="UTF-8"

Hi Beena,

This sounds like a great use of the client credentials grant. The password
grant is being removed from OAuth 2.0 by the Security Best Current
Practice. Can you clarify what you've found useful about the password grant
that the client credentials grant doesn't solve?

Aaron Parecki


On Sun, May 10, 2020 at 3:18 AM Beena Santhosh 
wrote:

> Hi,
>
>
> We have a product with client server architecture where our server manages
> thousands of devices. Each device has a client-piece that talks to the
> server over SOAP/REST. The client currently uses a HTTP Basic
> Authentication (unique id and a secret string) for all the calls. The
> secret string is created when the device enrolls to the server. It is
> available at the server as well as stored securely on the device. For the
> rest calls it is the device that is getting authenticated.
>
>
>
>  Sending the credentials every time is less than ideal and we want to move
> to some tokenized device authentication. We evaluated OpendID Connect based
> on the general recommendation of SSO solution, but the issue is we do not
> have any user interaction and hence there is no Grant flow that is fitting.
> Hence we evaluated OAuth grant type of which we found Password Grant and
> Client Credentials Grant is matching our requirement.
>
>
>
>  In order to use Client Credentials in our use case, we need to do dynamic
> registration for the thousands of devices managed by the server, if IoT
> comes into picture the number is going to be even higher, which is highly
> cumbersome to manage.  Also, as per  RFC7591 on dynamic client
> registration, using access token for registering client is optional too.
> Even though the Password grant is highly discouraged by the spec, we found
> it to be highly matching with our requirements.
>
>
>
> But as per the Oauth 2.1 proposal, password grant is going to be removed. Can
> you suggest the way forward for us? I believe we are not a one-off case.
>
>
> Thank You,
>
> Beena
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000f9b2e605a54beff6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


3D""=
=E1=90=A7


--000000000000b14fd605a55060d1--


From nobody Sun May 10 12:52:11 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001EB3A0B55 for ; Sun, 10 May 2020 12:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYUjZnr6DAyR for ; Sun, 10 May 2020 12:52:04 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640092.outbound.protection.outlook.com [40.107.64.92]) (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 04A583A0B58 for ; Sun, 10 May 2020 12:52:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q4Rk6VbTg9U0LVgilT7xuj5glhri60kpIfZ5yZu6mV3WPJHCHMtoPnKqTu+X9xQmuwpe+9Xr7y1NCTniv00inhQ+AHk+CAwqQokV6c/qhpu/ro/eUfoPk5X6jutL2qSlENymmKMiCd5UfvOX72YP5clfLerqa5o66XsLPOFVDLkgAEYilyPopJAQXGbFmWlW/ZjBv4ye/+cKnHm8VGB9CoCNoHalp/aalgv5yPK+RZrJB6kKroFX4adphs7T0YPu6OM350POOeayxbBjHdKAc6sHO2nb4thk2WLYMhEkT99l4xo0ra5RX7bfGlKEDH3p8gE4nqFQW+GOuMdtZyzX1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AE+JoobHaB+wUWNP9gCTxpIe3WWmmw1Y0sXgDDHdYag=; b=S2neiH8O0U09TlRPWAqo0pJQL1CdAkaGBfcAUevhb5IAnShxTHG/o16Mo8ZtmaCTc0qq/BlpCryb/0lPlwnw6gBI4fBEFnQtacf2B84v1Z6PfRds07zE6JcPi74IH9LZI8olRHiwXSe5TW1wThDO4myiYJ4BGFeUq296pUJVVh02DT6V/dScGfUux/l5aScvDKIF3pQRYJVz5R1EG7QSXjnPSQ5x/5SrFrNF34yjAUZtg4JZsJuxfwYqVqWPkxyU0edrtJ4M3hgBwqtPAALDcMF70H+fMrlX7VzPbi7nUIhIiVxY6dMdYuvMcctHAhpsWAjFx6mUirJ6nGMxKta96g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AE+JoobHaB+wUWNP9gCTxpIe3WWmmw1Y0sXgDDHdYag=; b=a35bJvohx4uOmRpCAqu/ndhTqXcAdj74UhNqM1HlDRMTynwI+dtF9RtzRvMC+v++ke9KbhaJ9B9iggZl/hLokFMtBlzIhcesFySBIVX+Fkn3iGBbGdj8+yra7dLZozWdgAMSM//a0Jr5wLIqOBiPm/9/jwmAD+wWszA1EZxh3bU=
Received: from MN2PR00MB0688.namprd00.prod.outlook.com (10.255.125.23) by BL0PR00MB0739.namprd00.prod.outlook.com (52.135.47.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3032.0; Sun, 10 May 2020 19:51:54 +0000
Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073%7]) with mapi id 15.20.3031.000; Sun, 10 May 2020 19:51:54 +0000
From: Mike Jones 
To: Dick Hardt 
CC: Torsten Lodderstedt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYnBHKyxZhADFzHRYqFfzkxHf5YHw==
Date: Sun, 10 May 2020 19:51:54 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1c3e1a2b-65a2-4dcb-9236-000083246527; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-10T19:44:44Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 244ef2ae-148e-4dff-d8e1-08d7f51b9743
x-ms-traffictypediagnostic: BL0PR00MB0739:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 039975700A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +Bh4U6Aixc1JswUfU7GENrpne49FwpPAQPtOkkrXpWQ1hS0b3Yxh9Oxe1LI3KQCZ7GXj2GCi4slvNoqcZQ0U3TcMvBjbAG4zciwGG07DxLOCoEDi1UpgcF45u08v/pqbeAKdQXAGYabpkON/UkgYOQLUahvdUPp53oR3CIajcqbrpSPlOAPGcstsrO009zCAeUKEMWmH0w/4Qy/uWVLdq6QSr7gLpi41lW6hwKDcuyvMJcIuKH37TN0d8p5d6dAanXGGmNRE0o+iRvBtJh9rK5LXXAErkWPkynffkRhbgOikHodaXU0ohtzC3F5KTZQ0rZqq6efW/D5rQ1Vi/u2xrNtfDKcdNKOWHhfd0WrRtV0Pz6+Tu8Fh8zLaDWQnuSkUc3BuC40jnf0k+ZCsbX+ZQCSc8DrqFG3PbR4WgEn2vQuisw07l1sooBfvdeMq8IMIXzM8WqjS7N8kPU4JIWOYQtrqoP2Omu8cSHnIiyTy+OVjarQv33kmPl6Qo6ZKoKPyW9yetvvIS5sbmwEbk8x65g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(33430700001)(53546011)(66446008)(71200400001)(9686003)(76236002)(55016002)(6506007)(8990500004)(10290500003)(316002)(54906003)(478600001)(66574014)(33440700001)(966005)(166002)(7696005)(52536014)(186003)(26005)(76116006)(33656002)(64756008)(6916009)(66556008)(66476007)(82960400001)(82950400001)(66946007)(4326008)(2906002)(5660300002)(8676002)(8936002)(86362001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: DtZslQXBxLXyJuzcNJbr5nytW8Cyla+a/8UGJMq3oVoRURyQq8u0f7zG9uqnRUPHuZYYa+gTaaXe6iZDeCyy+pz9XXyD1XrLQm8jh6Ip98aHxgi/y08DIPb8Gri8w4gAts2jVh6oT3hdAEkTwR9ytWXUrnzVr8D2qOqv3STCxoodbYdg8AJCTHtpdx6fLCLse0NVmC6frCaXO8s+5sYu/WILKthQ+ibChgUCawHjJB86i7Kms3nAKOBf/rBA4nbBD1qrb7+ZPD3EmaT6hIoZPOkmYRM2NHw5U/lk3fhobFSVnT8CgG+orHbwMikdGzmZFqRsszhd8RvTCUCkcrz/gV2XZ/3kc33MYAYQ7Ry1M5Lj7XPsjJNjsfKDSXETm/t6R6WlRD+7hu4cEJ7f1LI0HziSPijbtM9xrpiSLY0yvEkEt2Al6BKUQWqqSwuHYrLrAtPelCwcuVWe8fBIsgmaDyE5mK3k5SADiJiaqXA1zyE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB068869E4725F8EB1078ED2FDF5A00MN2PR00MB0688namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 244ef2ae-148e-4dff-d8e1-08d7f51b9743
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 19:51:54.5260 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: t3v5rZ3BY/cUTzAkrR80r+oxrsLwvyWwOxGVsB6OYABpzAAV/6i3LMyK/TUlRzu+chxNJr8YjcrF1efj/tN8PQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0739
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 19:52:10 -0000

--_000_MN2PR00MB068869E4725F8EB1078ED2FDF5A00MN2PR00MB0688namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgSeKAmW0gbm90IG1pc3Rha2VuLCB0aGUgT0F1dGggMi4xIGRyYWZ0IGlzIGludGVuZGVkIHRv
IG1ha2UgT0F1dGggMi4wIChSRkMgNjc0OSkgb2Jzb2xldGUsIGp1c3QgbGlrZSBPQXV0aCAyLjAg
KFJGQyA2NzQ5KSBtYWRlIE9BdXRoIDEuMCAoUkZDIDU4NDkpIG9ic29sZXRlLiAgVGhhdOKAmXMg
d2hhdCBtYWtlcyBtZSB0aGluayBkZXZlbG9wZXJzIHdvdWxkIHZpZXcgdXBkYXRpbmcgYXMgbWFu
ZGF0b3J5LiAgSWYgeW914oCZcmUgd2lsbGluZyB0byByZW1vdmUgdGhlIOKAnHJlcGxhY2VzIDY3
NDnigJ0gY2xhdXNlIGZyb20gdGhlIGRyYWZ0LCB0aGVuIHRoZXJlIHdvdWxkIGJlIG5vIHBlcmNl
cHRpb24gcHJvYmxlbSwgYXMgaXQgd291bGQgYmUgY2xlYXIgdGhhdCBhZG9wdGlvbiBvZiAyLjEg
d291bGQgYmUgdm9sdW50YXJ5LCBqdXN0IGxpa2UgdGhlIG90aGVyIGV4dGVuc2lvbiBzcGVjcy4N
Cg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpTZW50OiBTdW5kYXks
IE1heSAxMCwgMjAyMCAxMjozOCBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbT4NCkNjOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0
Lm5ldD47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEg
LSByZXF1aXJlIFBLQ0U/DQoNCkhpIE1pa2UsIEkgd291bGQgY29uc2lkZXIgdXBncmFkaW5nIHRv
IE9BdXRoIDIuMSB0byBiZSB2b2x1bnRhcnksIGp1c3QgYXMgdGhlIG90aGVyIGV4dGVuc2lvbnMu
IFNpbWlsYXJseSwgT0F1dGggMS4wIGRlcGxveW1lbnRzIHVwZ3JhZGluZyB0byBPQXV0aCAyLjAg
d2FzIHZvbHVudGFyeS4NCg0KV291bGQgeW91IGNsYXJpZnkgd2h5IHlvdSB0aGluayB1cGdyYWRp
bmcgdG8gT0F1dGggMi4xIHdvdWxkIGJlIG1hbmRhdG9yeT8NCg0KDQpPbiBTdW4sIE1heSAxMCwg
MjAyMCBhdCAxMjowMiBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNv
bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4g
d3JvdGU6DQpJIGFncmVlIHdpdGggYWN0aXZlbHkgbWFpbnRhaW5pbmcgYW5kIGltcHJvdmluZyB0
aGUgT0F1dGggMi4wIHNwZWNzIGJ5IGFkZGluZyBlbmhhbmNlbWVudHMgdGhhdCBhcmUgdm9sdW50
YXJ5IHRvIHVzZS4gIEnigJl2ZSB3b3JrZWQgb24gbWFueSBzdWNoIGltcHJvdmVtZW50cywgaW5j
bHVkaW5nIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiwgQXV0aG9yaXphdGlvbiBNZXRhZGF0
YSwgdGhlIERldmljZSBGbG93LCBUb2tlbiBFeGNoYW5nZSwgRFBvUCwgYW5kIHN1cHBvcnQgUEFS
IGFuZCBSQVIsIGV0Yy4gIFRoZSBpc3N1ZSB0aGF04oCZcyB0aGUgc3ViamVjdCBpcyB0aGUgY3Vy
cmVudCBkaXNjdXNzaW9uIGlzIHdoZXRoZXIgdG8gbWFrZSB1c2Ugb2YgYW5vdGhlciBlbmhhbmNl
bWVudCwgUEtDRSwgbWFuZGF0b3J5IGluIGNhc2VzIHdoZXJlIGl04oCZcyBhY3R1YWxseSBub3Qg
bmVlZGVkLCByYXRoZXIgdGhhbiBtYWtpbmcgaXRzIHVzZSB2b2x1bnRhcnkgbGlrZSB0aGUgb3Ro
ZXIgZW5oYW5jZW1lbnRzLCB3aGljaCBJIGNlcnRhaW5seSBzdXBwb3J0Lg0KDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG
cm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJj
LmlldGYub3JnPG1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+DQpTZW50
OiBTdW5kYXksIE1heSAxMCwgMjAyMCAzOjE1IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0K
Q2M6IERhbmllbCBGZXR0IDxmZXR0QGRhbmllbGZldHQuZGU8bWFpbHRvOmZldHRAZGFuaWVsZmV0
dC5kZT4+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb
RVhURVJOQUxdIFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KSGkg
TWlrZSwNCg0KTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMu
aWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHNjaHJpZWIg
YW0gRnIuIDguIE1haSAyMDIwIHVtIDE4OjU1Og0KT0F1dGggMi4xIHdhcyBzdXBwb3NlZCB0byBu
b3QgaW50cm9kdWNlIGJyZWFraW5nIGNoYW5nZXMuDQpJIGNhbm5vdCByZW1lbWJlciB0aGUgV0cg
bWV0IHRoYXQgZGVjaXNpb24uIENhbiB5b3UgcGxlYXNlIHJlZmVyIHRvIHRoZSByZXNwZWN0aXZl
IHRocmVhZD8NCg0KUmVxdWlyaW5nIGV4YWN0IHJlZGlyZWN0IFVSSSBtYXRjaGluZyBpcyBhbHJl
YWR5IGEgYnJlYWtpbmcgY2hhbmdlLiBEbyB5b3Ugb3Bwb3NlIGFnYWluc3QgdGhpcyBhcyB3ZWxs
Pw0KDQoNCklmIHlvdSB3YW50IHRvIGRvIHRoYXQsIHBsZWFzZSBkbyBpdCBpbiBUeEF1dGggaW5z
dGVhZC4NCg0KSW50ZXJlc3Rpbmcgc3RhdGVtZW50LiBEb2VzIGl0IG1lYW4geW91IHdhbnQgdG8g
Y29uc2VydmUgT0F1dGggMi4wIGFuZCBmb3JjZSBhbnkgZW5oYW5jZW1lbnRzL2ltcHJvdmVtZW50
cyB0byBnbyBpbnRvIFRYQXV0aD8gVGhpcyB3b3VsZCBjYXVzZSBodWdlIG1pZ3JhdGlvbiBlZmZv
cnRzIGZvciBleGlzdGluZyBkZXBsb3ltZW50cyB3YW50aW5nIHRvIGJlbmVmaXQgZnJvbSB0aG9z
ZSBlbmhhbmNlbWVudHMuDQoNCkkgdGhpbmsgZXhpc3RpbmcgZGVwbG95bWVudHMgYXJlIGJldHRl
ciBzZXJ2ZWQgYnkgYWN0aXZlbHkgbWFpbnRhaW5pbmcgYW5kIGV2b2x2aW5nIHRoZSAyLnggbGlu
ZS4gRm9yIGV4YW1wbGUsIFBBUiBhbmQgUkFSIGFyZSBhdHRlbXB0cyB0byBpbXByb3ZlIE9BdXRo
IDIueCBhbmQgbWFrZSBpdCB1c2FibGUgZm9yIG5ldyB1c2UgY2FzZXMuIFRoYXTigJlzIGJldHRl
ciBwcm90ZWN0aW9uIG9mIGV4aXN0aW5nIGludmVzdG1lbnRzIHRoYW4gc2VuZGluZyB0aGVtIG9m
IHRvIFRYQXV0aC4NCktpbmQgcmVnYXJkcywNClRvcnN0ZW4uDQoNCg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog
T0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmc+PiBPbiBCZWhhbGYgT2YgRGFuaWVsIEZldHQNClNlbnQ6IFRodXJzZGF5LCBNYXkgNywgMjAy
MCAxMTo1MCBQTQ0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1
YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KKzEgdG8g
YWxsIHdoYXQgQWFyb24gc2FpZC4gVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dCENCg0KV2Ug
bmVlZCB0byBhZGRyZXNzIHRoaXMgaW4gdGhlIHNlY3VyaXR5IEJDUCBhbmQgdGhpcyB3aWxsIGJl
IGEgbm9ybWF0aXZlIGNoYW5nZSB0aGF0IGFmZmVjdHMgT3BlbklEIENvbm5lY3QgQ29yZSAoanVz
dCBhcyBvdXIgY3VycmVudCByZWNvbW1lbmRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2Ygbm9uY2UpLg0K
DQpXZSB3b3VsZCB0aGVuIGhhdmU6DQoNCi0gdXNlIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgdXNlIE9J
REMgd2l0aCBhIG5vbmNlLCB0aGVuIHlvdSBkb24ndCBuZWVkIFBLQ0UsIGV4Y2VwdCBpZiB5b3Ug
YXJlIGEgcHVibGljIGNsaWVudCwgdGhlbiB5b3Ugc3RpbGwgbmVlZCBQS0NFLg0KLSB1c2Ugc3Rh
dGUsIGV4Y2VwdCBpZiB5b3UgdXNlIFBLQ0UsIHRoZW4geW91IGRvbid0IG5lZWQgc3RhdGUuDQoN
CkkgdGhpbmsgdGhlcmUgYXJlIHZlcnkgZ29vZCByZWFzb25zIHRvIHNpbXBsaWZ5IHRoaXMgZG93
biB0bw0KDQotIHVzZSBQS0NFDQotIHlvdSBtYXkgb3IgbWF5IG5vdCB1c2Ugc3RhdGUNCg0KRmly
c3QgYW5kIGZvcmVtb3N0LCBub3QgbWFueSBwZW9wbGUgd2lsbCB1bmRlcnN0YW5kIHdoeSB0aGVy
ZSBhcmUgY2FzZXMgd2hlbiB0aGUgQkNQL09BdXRoIDIuMSBtYW5kYXRlIFBLQ0UgYW5kIHNvbWUg
d2hlcmUgdGhleSBkb24ndC4gSG93ZXZlciwgdW5kZXJzdGFuZGluZyB3aHkgeW91IGhhdmUgdG8g
ZG8gc29tZXRoaW5nIGlzIGtleSB0byBjb21wbGlhbmNlLiBUaGUgc2hvcnQgdmVyc2lvbiAiUEtD
RSBwcm90ZWN0cyB0aGUgY29kZTsgdGhlcmUgaXMgYSBzcGVjaWZpYyBjYXNlIHdoZXJlIGl0IGlz
IG5vdCBuZWVkZWQsIGJ1dCBpdHMgYmV0dGVyIHRvIHVzZSBpdCBhbGwgdGhlIHRpbWUiIGlzIGVh
c3kgdG8gdW5kZXJzdGFuZC4gV2Ugd2lsbCBub3Qgc2VlIG1hbnkgaW1wbGVtZW50YXRpb25zIGZv
bGxvd2luZyB0aGUgbG9uZyB2ZXJzaW9uIGFib3ZlIGNvcnJlY3RseS4NCg0KU2Vjb25kLCB3ZSBk
cmFtYXRpY2FsbHkgcmVkdWNlIHRlY2huaWNhbCBjb21wbGV4aXR5IGJ5IHJlZHVjaW5nIGNhc2Vz
IHRoYXQgbmVlZCB0byBiZSBoYW5kbGVkLiBXZSByZWR1Y2UgY29ycmVjdG5lc3MgYW5kIGNvbXBs
aWFuY2UgdGVzdGluZyBjb21wbGV4aXR5IGluIHRoZSBzYW1lIHdheS4gV2UgcmVkdWNlIHRoZSBj
b3N0IG9mIHNlY3VyaXR5IGFuYWx5c2lzLCB3aGljaCBzY2FsZXMgcmVhbGx5IGJhZGx5IHRvIG1v
cmUgY2FzZXMuDQoNCkFuZCBmaW5hbGx5LCB1c2luZyBub25jZSB0byBwcm90ZWN0IGFnYWluc3Qg
Y29kZSBpbmplY3Rpb24gaXMgbGVzcyByb2J1c3QgdGhhbiBQS0NFLiBBUyBoYXZlIGEgYmV0dGVy
IHRyYWNrIHJlY29yZCB0aGFuIGNsaWVudHMgd2hlbiBpdCBjb21lcyB0byBjb3JyZWN0bHkgaW1w
bGVtZW50aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQoNClllcywgdGhpcyB3aWxsIG1ha2UgYSBu
dW1iZXIgb2YgaW1wbGVtZW50YXRpb25zIG5vbi1zcGVjLWNvbXBsaWFudCwgYnV0IEkgZG8gbm90
IHRoaW5rIHRoYXQgdGhpcyBpcyBhIGh1Z2UgcHJvYmxlbS4gU29mdHdhcmUgbmVlZHMgdG8gYWRh
cHQgYWxsIHRoZSB0aW1lIGFuZCBhIHNvZnR3YXJlIHRoYXQgaGFzIG5vdCBiZWVuIGNoYW5nZWQg
aW4gYSB3aGlsZSBpcyBwcm9iYWJseSBub3Qgb25lIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhbnl3
YXkuIFdlIGFyZSBzZXR0aW5nIGEgbmV3IGdvYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byBtZWV0
IGFuZCBldmVudHVhbGx5LCBtYWludGFpbmVkIGltcGxlbWVudGF0aW9ucyB3aWxsIGdldCB0aGVy
ZS4NCg0KLURhbmllbA0KDQoNCkFtIDA4LjA1LjIwIHVtIDAxOjM4IHNjaHJpZWIgQWFyb24gUGFy
ZWNraToNCkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUncyBhbm90aGVyIHBvaW50IGhl
cmUgdGhhdCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVzZSBkaXNjdXNzaW9ucy4NCg0K
UEtDRSBzb2x2ZXMgdHdvIHByb2JsZW1zOiBzdG9sZW4gYXV0aG9yaXphdGlvbiBjb2RlcyBmb3Ig
cHVibGljIGNsaWVudHMsIGFuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGZvciBhbGwg
Y2xpZW50cy4gV2UndmUgb25seSBiZWVuIHRhbGtpbmcgYWJvdXQgYXV0aG9yaXphdGlvbiBjb2Rl
IGluamVjdGlvbiBvbiB0aGUgbGlzdCBzbyBmYXIuIFRoZSBxdW90ZWQgc2VjdGlvbiBvZiB0aGUg
c2VjdXJpdHkgQkNQICg0LjUuMykgd2hpY2ggc2F5cyBjbGllbnRzIGNhbiBkbyBQS0NFIG9yIHVz
ZSB0aGUgbm9uY2UsIGlzIG9ubHkgdGFsa2luZyBhYm91dCBwcmV2ZW50aW5nIGF1dGhvcml6YXRp
b24gY29kZSBpbmplY3Rpb24uDQoNClRoZSBub25jZSBwYXJhbWV0ZXIgc29sdmVzIGF1dGhvcml6
YXRpb24gY29kZSBpbmplY3Rpb24gaWYgdGhlIGNsaWVudCByZXF1ZXN0cyBhbiBJRCB0b2tlbi4g
UHVibGljIGNsaWVudHMgdXNpbmcgdGhlIG5vbmNlIHBhcmFtZXRlciBhcmUgc3RpbGwgc3VzY2Vw
dGlibGUgdG8gc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgc28gdGhleSBzdGlsbCBuZWVkIHRv
IGRvIFBLQ0UgYXMgd2VsbC4NCg0KVGhlIG9ubHkgY2FzZSB3aGVyZSBPcGVuSUQgQ29ubmVjdCBj
bGllbnRzIGRvbid0IGJlbmVmaXQgZnJvbSBQS0NFIGlzIGlmIHRoZXkgYXJlIGFsc28gY29uZmlk
ZW50aWFsIGNsaWVudHMuIFB1YmxpYyBjbGllbnQgT0lEQyBjbGllbnRzIHN0aWxsIG5lZWQgdG8g
ZG8gUEtDRSBldmVuIGlmIHRoZXkgY2hlY2sgdGhlIG5vbmNlLg0KDQpPcGVuSUQgQ29ubmVjdCBz
ZXJ2ZXJzIHdvcmtpbmcgd2l0aCBjb25maWRlbnRpYWwgY2xpZW50cyBzdGlsbCBiZW5lZml0IGZy
b20gUEtDRSBiZWNhdXNlIHRoZXkgY2FuIHRoZW4gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbiBj
b2RlIGluamVjdGlvbiBwcm90ZWN0aW9uIHNlcnZlci1zaWRlIHJhdGhlciB0aGFuIGNyb3NzIHRo
ZWlyIGZpbmdlcnMgdGhhdCBjbGllbnRzIGltcGxlbWVudGVkIHRoZSBub25jZSBjaGVjayBwcm9w
ZXJseS4NCg0KSSByZWFsbHkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0aCB0aGUgYW1vdW50IG9mIGV4
cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtlIGluIHRoZSBmdXR1cmUgdG8gd3JpdGUgYW4gZXhjZXB0
aW9uIGludG8gT0F1dGggMi4xIG9yIHRoZSBTZWN1cml0eSBCQ1AgZm9yIG9ubHkgc29tZSB0eXBl
cyBvZiBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIHdoZW4gYWxsIGNsaWVudHMgd291bGQgYmVuZWZp
dCBmcm9tIFBLQ0UgYW55d2F5Lg0KDQpBYXJvbg0KDQoNCg0KT24gV2VkLCBNYXkgNiwgMjAyMCBh
dCAxMDo0OCBBTSBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5o
YXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkhlbGxvIQ0KDQpXZSB3b3VsZCBsaWtlIHRvIGhhdmUg
UEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUgZmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFj
dGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29tbW9uIGluIE9wZW5JRCBDb25uZWN0IHNl
cnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9mIHRoZSBpc3N1ZXMgdGhhdCBQS0NFIHBy
b3RlY3RzIGFnYWluc3QuIFdlIHRoaW5rIHRoYXQgbW9zdCBPcGVuSUQgQ29ubmVjdCBpbXBsZW1l
bnRhdGlvbnMgYWxzbyBzdXBwb3J0IE9BdXRoIDIuMCwgYW5kIGhlbmNlIGhhdmUgc3VwcG9ydCBm
b3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMuDQoNClRoZSBhZHZhbnRhZ2VzIG9y
IHJlcXVpcmluZyBQS0NFIGFyZToNCg0KLSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNy
b3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQ
S0NFDQoNCi0gcmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3aGVuIHVzaW5nICBTMjU2IGFzIGEgZmlu
Z2VycHJpbnQgb2YgdGhlIHZlcmlmaWVyIGlzIHNlbnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0
ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZhbHVlDQoNCi0gZW5mb3JjZW1lbnQgYnkgQVMgbm90IGNs
aWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUgZm9yIGNsaWVudCBkZXZlbG9wZXJzIGFu
ZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25kdWN0ZWQNCg0KV2hhdCBhcmUgZGlzYWR2
YW50YWdlcyBiZXNpZGVzIHRoZSBwb3RlbnRpYWwgaW1wYWN0IHRvIE9wZW5JRCBDb25uZWN0IGRl
cGxveW1lbnRzPyBIb3cgc2lnbmlmaWNhbnQgaXMgdGhhdCBpbXBhY3Q/DQoNCkRpY2ssIEFhcm9u
LCBhbmQgVG9yc3Rlbg0KDQrhkKcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K4ZCnDQo=

--_000_MN2PR00MB068869E4725F8EB1078ED2FDF5A00MN2PR00MB0688namp_
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
bWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz
O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K
PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91
dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SWYgSeKA
mW0gbm90IG1pc3Rha2VuLCB0aGUgT0F1dGggMi4xIGRyYWZ0IGlzIGludGVuZGVkIHRvIG1ha2Ug
T0F1dGggMi4wIChSRkMgNjc0OSkgb2Jzb2xldGUsIGp1c3QgbGlrZSBPQXV0aCAyLjAgKFJGQyA2
NzQ5KSBtYWRlIE9BdXRoIDEuMCAoUkZDIDU4NDkpIG9ic29sZXRlLiZuYnNwOyBUaGF04oCZcyB3
aGF0IG1ha2VzIG1lIHRoaW5rIGRldmVsb3BlcnMgd291bGQgdmlldw0KIHVwZGF0aW5nIGFzIG1h
bmRhdG9yeS4mbmJzcDsgSWYgeW914oCZcmUgd2lsbGluZyB0byByZW1vdmUgdGhlIOKAnHJlcGxh
Y2VzIDY3NDnigJ0gY2xhdXNlIGZyb20gdGhlIGRyYWZ0LCB0aGVuIHRoZXJlIHdvdWxkIGJlIG5v
IHBlcmNlcHRpb24gcHJvYmxlbSwgYXMgaXQgd291bGQgYmUgY2xlYXIgdGhhdCBhZG9wdGlvbiBv
ZiAyLjEgd291bGQgYmUgdm9sdW50YXJ5LCBqdXN0IGxpa2UgdGhlIG90aGVyIGV4dGVuc2lvbiBz
cGVjcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IERp
Y2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4g
U3VuZGF5LCBNYXkgMTAsIDIwMjAgMTI6MzggUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMg
Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRvcnN0
ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0Ozsgb2F1dGhAaWV0
Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVx
dWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SGkgTWlrZSwgSSB3b3VsZCBjb25zaWRlciB1cGdyYWRpbmcgdG8gT0F1dGggMi4xIHRvIGJlIHZv
bHVudGFyeSwganVzdCBhcyB0aGUgb3RoZXIgZXh0ZW5zaW9ucy4gU2ltaWxhcmx5LCBPQXV0aCAx
LjAgZGVwbG95bWVudHMgdXBncmFkaW5nIHRvIE9BdXRoIDIuMCB3YXMgdm9sdW50YXJ5LiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgeW91
IGNsYXJpZnkgd2h5IHlvdSB0aGluayB1cGdyYWRpbmcmbmJzcDt0byBPQXV0aCAyLjEgd291bGQg
YmUgbWFuZGF0b3J5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIFN1biwgTWF5IDEwLCAyMDIwIGF0IDEyOjAyIFBNIE1pa2UgSm9uZXMg
Jmx0O01pY2hhZWwuSm9uZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p
ZXRmLm9yZyI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgYWdyZWUgd2l0aCBh
Y3RpdmVseSBtYWludGFpbmluZyBhbmQgaW1wcm92aW5nIHRoZSBPQXV0aCAyLjAgc3BlY3MgYnkg
YWRkaW5nIGVuaGFuY2VtZW50cyB0aGF0IGFyZSB2b2x1bnRhcnkgdG8gdXNlLiZuYnNwOyBJ4oCZ
dmUgd29ya2VkIG9uIG1hbnkgc3VjaCBpbXByb3ZlbWVudHMsDQogaW5jbHVkaW5nIER5bmFtaWMg
Q2xpZW50IFJlZ2lzdHJhdGlvbiwgQXV0aG9yaXphdGlvbiBNZXRhZGF0YSwgdGhlIERldmljZSBG
bG93LCBUb2tlbiBFeGNoYW5nZSwgRFBvUCwgYW5kIHN1cHBvcnQgUEFSIGFuZCBSQVIsIGV0Yy4m
bmJzcDsgVGhlIGlzc3VlIHRoYXTigJlzIHRoZSBzdWJqZWN0IGlzIHRoZSBjdXJyZW50IGRpc2N1
c3Npb24gaXMgd2hldGhlciB0byBtYWtlIHVzZSBvZiBhbm90aGVyIGVuaGFuY2VtZW50LCBQS0NF
LCBtYW5kYXRvcnkgaW4gY2FzZXMNCiB3aGVyZSBpdOKAmXMgYWN0dWFsbHkgbm90IG5lZWRlZCwg
cmF0aGVyIHRoYW4gbWFraW5nIGl0cyB1c2Ugdm9sdW50YXJ5IGxpa2UgdGhlIG90aGVyIGVuaGFu
Y2VtZW50cywgd2hpY2ggSSBjZXJ0YWlubHkgc3VwcG9ydC48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJv
bTo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49PGEgaHJlZj0ibWFpbHRvOjQw
bG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBsb2RkZXJz
dGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh
eSwgTWF5IDEwLCAyMDIwIDM6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0Ozxh
IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r
Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRGFu
aWVsIEZldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmZXR0QGRhbmllbGZldHQuZGUiIHRhcmdldD0i
X2JsYW5rIj5mZXR0QGRhbmllbGZldHQuZGU8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpvYXV0
aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1
YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUg
UEtDRT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I
aSBNaWtlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPk1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9PGEgaHJlZj0ibWFp
bHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWlj
cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHNjaHJpZWIgYW0gRnIuIDguIE1haSAy
MDIwIHVtIDE4OjU1OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90
dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjQuLjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk9BdXRoIDIuMSB3YXMgc3Vw
cG9zZWQgdG8gbm90IGludHJvZHVjZSBicmVha2luZyBjaGFuZ2VzLiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5JIGNhbm5vdCByZW1lbWJlciB0aGUgV0cgbWV0IHRoYXQgZGVjaXNp
b24uIENhbiB5b3UgcGxlYXNlIHJlZmVyIHRvIHRoZSByZXNwZWN0aXZlIHRocmVhZD8mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlJlcXVpcmluZyBleGFjdCByZWRpcmVjdCBVUkkgbWF0Y2hpbmcgaXMgYWxyZWFkeSBhIGJyZWFr
aW5nIGNoYW5nZS4gRG8geW91IG9wcG9zZSBhZ2FpbnN0IHRoaXMgYXMgd2VsbD88bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdp
bi1sZWZ0OjQuLjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPklmIHlvdSB3YW50IHRvIGRvIHRoYXQsIHBsZWFzZSBk
byBpdCBpbiBUeEF1dGggaW5zdGVhZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklu
dGVyZXN0aW5nIHN0YXRlbWVudC4gRG9lcyBpdCBtZWFuIHlvdSB3YW50IHRvIGNvbnNlcnZlIE9B
dXRoIDIuMCBhbmQgZm9yY2UgYW55IGVuaGFuY2VtZW50cy9pbXByb3ZlbWVudHMgdG8gZ28gaW50
byBUWEF1dGg/IFRoaXMgd291bGQgY2F1c2UgaHVnZSBtaWdyYXRpb24gZWZmb3J0cyBmb3IgZXhp
c3RpbmcNCiBkZXBsb3ltZW50cyB3YW50aW5nIHRvIGJlbmVmaXQgZnJvbSB0aG9zZSBlbmhhbmNl
bWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5JIHRoaW5rIGV4aXN0aW5nIGRlcGxveW1lbnRzIGFyZSBiZXR0ZXIgc2VydmVkIGJ5
IGFjdGl2ZWx5IG1haW50YWluaW5nIGFuZCBldm9sdmluZyB0aGUgMi54IGxpbmUuIEZvciBleGFt
cGxlLCBQQVIgYW5kIFJBUiBhcmUgYXR0ZW1wdHMgdG8gaW1wcm92ZSBPQXV0aCAyLnggYW5kIG1h
a2UgaXQgdXNhYmxlIGZvcg0KIG5ldyB1c2UgY2FzZXMuIFRoYXTigJlzIGJldHRlciBwcm90ZWN0
aW9uIG9mIGV4aXN0aW5nIGludmVzdG1lbnRzIHRoYW4gc2VuZGluZyB0aGVtIG9mIHRvIFRYQXV0
aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5Ub3JzdGVuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47
bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDo0Li44cHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
LS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w
cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi
PkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9u
IEJlaGFsZiBPZiA8L2I+RGFuaWVsIEZldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1h
eSA3LCAyMDIwIDExOjUwIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mIzQzOzEgdG8gYWxs
IHdoYXQgQWFyb24gc2FpZC4gVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dCE8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIG5lZWQg
dG8gYWRkcmVzcyB0aGlzIGluIHRoZSBzZWN1cml0eSBCQ1AgYW5kIHRoaXMgd2lsbCBiZSBhIG5v
cm1hdGl2ZSBjaGFuZ2UgdGhhdCBhZmZlY3RzIE9wZW5JRCBDb25uZWN0IENvcmUgKGp1c3QgYXMg
b3VyIGN1cnJlbnQgcmVjb21tZW5kYXRpb24gb24gdGhlIHVzYWdlIG9mIG5vbmNlKS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIHdv
dWxkIHRoZW4gaGF2ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPi0gdXNlIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgdXNlIE9JREMgd2l0aCBh
IG5vbmNlLCB0aGVuIHlvdSBkb24ndCBuZWVkIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgYXJlIGEgcHVi
bGljIGNsaWVudCwgdGhlbiB5b3Ugc3RpbGwgbmVlZCBQS0NFLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHVzZSBzdGF0ZSwgZXhjZXB0IGlm
IHlvdSB1c2UgUEtDRSwgdGhlbiB5b3UgZG9uJ3QgbmVlZCBzdGF0ZS48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhlcmUg
YXJlIHZlcnkgZ29vZCByZWFzb25zIHRvIHNpbXBsaWZ5IHRoaXMgZG93biB0bw0KPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHVzZSBQ
S0NFPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
Pi0geW91IG1heSBvciBtYXkgbm90IHVzZSBzdGF0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rmlyc3QgYW5kIGZvcmVtb3N0LCBub3Qg
bWFueSBwZW9wbGUgd2lsbCB1bmRlcnN0YW5kIHdoeSB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUg
QkNQL09BdXRoIDIuMSBtYW5kYXRlIFBLQ0UgYW5kIHNvbWUgd2hlcmUgdGhleSBkb24ndC4gSG93
ZXZlciwgdW5kZXJzdGFuZGluZw0KPGk+d2h5PC9pPiB5b3UgaGF2ZSB0byBkbyBzb21ldGhpbmcg
aXMga2V5IHRvIGNvbXBsaWFuY2UuIFRoZSBzaG9ydCB2ZXJzaW9uICZxdW90O1BLQ0UgcHJvdGVj
dHMgdGhlIGNvZGU7IHRoZXJlIGlzIGEgc3BlY2lmaWMgY2FzZSB3aGVyZSBpdCBpcyBub3QgbmVl
ZGVkLCBidXQgaXRzIGJldHRlciB0byB1c2UgaXQgYWxsIHRoZSB0aW1lJnF1b3Q7IGlzIGVhc3kg
dG8gdW5kZXJzdGFuZC4gV2Ugd2lsbCBub3Qgc2VlIG1hbnkgaW1wbGVtZW50YXRpb25zIGZvbGxv
d2luZw0KIHRoZSBsb25nIHZlcnNpb24gYWJvdmUgY29ycmVjdGx5LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2Vjb25kLCB3ZSBkcmFt
YXRpY2FsbHkgcmVkdWNlIHRlY2huaWNhbCBjb21wbGV4aXR5IGJ5IHJlZHVjaW5nIGNhc2VzIHRo
YXQgbmVlZCB0byBiZSBoYW5kbGVkLiBXZSByZWR1Y2UgY29ycmVjdG5lc3MgYW5kIGNvbXBsaWFu
Y2UgdGVzdGluZyBjb21wbGV4aXR5IGluIHRoZSBzYW1lIHdheS4gV2UgcmVkdWNlDQogdGhlIGNv
c3Qgb2Ygc2VjdXJpdHkgYW5hbHlzaXMsIHdoaWNoIHNjYWxlcyByZWFsbHkgYmFkbHkgdG8gbW9y
ZSBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkFuZCBmaW5hbGx5LCB1c2luZyBub25jZSB0byBwcm90ZWN0IGFnYWluc3QgY29k
ZSBpbmplY3Rpb24gaXMgbGVzcyByb2J1c3QgdGhhbiBQS0NFLiBBUyBoYXZlIGEgYmV0dGVyIHRy
YWNrIHJlY29yZCB0aGFuIGNsaWVudHMgd2hlbiBpdCBjb21lcyB0byBjb3JyZWN0bHkgaW1wbGVt
ZW50aW5nIHNlY3VyaXR5DQogbWVjaGFuaXNtcy4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIHRoaXMgd2lsbCBtYWtlIGEgbnVt
YmVyIG9mIGltcGxlbWVudGF0aW9ucyBub24tc3BlYy1jb21wbGlhbnQsIGJ1dCBJIGRvIG5vdCB0
aGluayB0aGF0IHRoaXMgaXMgYSBodWdlIHByb2JsZW0uIFNvZnR3YXJlIG5lZWRzIHRvIGFkYXB0
IGFsbCB0aGUgdGltZSBhbmQgYSBzb2Z0d2FyZSB0aGF0IGhhcw0KIG5vdCBiZWVuIGNoYW5nZWQg
aW4gYSB3aGlsZSBpcyBwcm9iYWJseSBub3Qgb25lIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhbnl3
YXkuIFdlIGFyZSBzZXR0aW5nIGEgbmV3IGdvYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byBtZWV0
IGFuZCBldmVudHVhbGx5LCBtYWludGFpbmVkIGltcGxlbWVudGF0aW9ucyB3aWxsIGdldCB0aGVy
ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPi1EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5BbSAwOC4wNS4yMCB1bSAwMTozOCBzY2hyaWViIEFhcm9uIFBhcmVj
a2k6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUncyBhbm90aGVyIHBvaW50
IGhlcmUgdGhhdCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVzZSBkaXNjdXNzaW9ucy4N
CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBLQ0Ug
c29sdmVzIHR3byBwcm9ibGVtczogc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgZm9yIHB1Ymxp
YyBjbGllbnRzLCBhbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBmb3IgYWxsIGNsaWVu
dHMuIFdlJ3ZlIG9ubHkgYmVlbiB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRpb24gY29kZSBpbmpl
Y3Rpb24NCiBvbiB0aGUgbGlzdCBzbyBmYXIuIFRoZSBxdW90ZWQgc2VjdGlvbiBvZiB0aGUgc2Vj
dXJpdHkgQkNQICg0LjUuMykgd2hpY2ggc2F5cyBjbGllbnRzIGNhbiBkbyBQS0NFIG9yIHVzZSB0
aGUgbm9uY2UsIGlzIG9ubHkgdGFsa2luZyBhYm91dCBwcmV2ZW50aW5nIGF1dGhvcml6YXRpb24g
Y29kZSBpbmplY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5UaGUgbm9uY2UgcGFyYW1ldGVyIHNvbHZlcyBhdXRob3JpemF0aW9u
IGNvZGUgaW5qZWN0aW9uIGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gSUQgdG9rZW4uIFB1Ymxp
YyBjbGllbnRzIHVzaW5nIHRoZSBub25jZSBwYXJhbWV0ZXIgYXJlIHN0aWxsIHN1c2NlcHRpYmxl
IHRvIHN0b2xlbiBhdXRob3JpemF0aW9uDQogY29kZXMgc28gdGhleSBzdGlsbCBuZWVkIHRvIGRv
IFBLQ0UgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlRoZSBvbmx5IGNhc2Ugd2hlcmUgT3BlbklEIENvbm5lY3QgY2xpZW50
cyBkb24ndCBiZW5lZml0IGZyb20gUEtDRSBpcyBpZiB0aGV5IGFyZSBhbHNvIGNvbmZpZGVudGlh
bCBjbGllbnRzLiBQdWJsaWMgY2xpZW50IE9JREMgY2xpZW50cyBzdGlsbCBuZWVkIHRvIGRvIFBL
Q0UgZXZlbiBpZiB0aGV5IGNoZWNrDQogdGhlIG5vbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3BlbklEIENvbm5lY3Qgc2VydmVy
cyB3b3JraW5nIHdpdGggY29uZmlkZW50aWFsIGNsaWVudHMgc3RpbGwgYmVuZWZpdCBmcm9tIFBL
Q0UgYmVjYXVzZSB0aGV5IGNhbiB0aGVuIGVuZm9yY2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBp
bmplY3Rpb24gcHJvdGVjdGlvbiBzZXJ2ZXItc2lkZSZuYnNwO3JhdGhlciZuYnNwO3RoYW4NCiBj
cm9zcyB0aGVpciBmaW5nZXJzIHRoYXQgY2xpZW50cyBpbXBsZW1lbnRlZCB0aGUgbm9uY2UgY2hl
Y2sgcHJvcGVybHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5JIHJlYWxseSBkb24ndCB0aGluayBpdCdzIHdvcnRoIHRoZSBhbW91bnQg
b2YgZXhwbGFuYXRpb24gdGhpcyB3aWxsIHRha2UgaW4gdGhlIGZ1dHVyZSB0byB3cml0ZSBhbiBl
eGNlcHRpb24gaW50byBPQXV0aCAyLjEgb3IgdGhlIFNlY3VyaXR5IEJDUCBmb3Igb25seSBzb21l
IHR5cGVzIG9mIE9wZW5JRCBDb25uZWN0DQogY2xpZW50cyB3aGVuIGFsbCBjbGllbnRzIHdvdWxk
IGJlbmVmaXQgZnJvbSBQS0NFIGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFhcm9uPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgTWF5IDYs
IDIwMjAgYXQgMTA6NDggQU0gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy
ZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp
biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow
aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+SGVsbG8hDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5XZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4x
IGNvZGUgZmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBu
b3QgY29tbW9uIGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBz
b21lIG9mIHRoZSBpc3N1ZXMNCiB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsg
dGhhdCBtb3N0IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1
dGggMi4wLCBhbmQgaGVuY2UmbmJzcDtoYXZlIHN1cHBvcnQgZm9yIFBLQ0UgaWYgZm9sbG93aW5n
IGJlc3QgcHJhY3RpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+VGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
LSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlv
bnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NFPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHJlZHVjZWQgYXR0YWNrIHN1
cmZhY2Ugd2hlbiB1c2luZyZuYnNwOyBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlm
aWVyIGlzIHNlbnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0
IHZhbHVlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4tIGVuZm9yY2VtZW50IGJ5IEFTIG5vdCBjbGllbnQgLSBtYWtlcyBpdCBlYXNpZXIg
dG8gaGFuZGxlIGZvciBjbGllbnQgZGV2ZWxvcGVycyBhbmQgQVMgY2FuIGVuc3VyZSB0aGUgY2hl
Y2sgaXMgY29uZHVjdGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5XaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVu
dGlhbCBpbXBhY3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2Fu
dCBpcyB0aGF0IGltcGFjdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkRpY2ssIEFhcm9uLCBhbmQgVG9yc3RlbjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBzdHlsZT0id2lkdGg6LjAx
MDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwczovL21haWxm
b29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUz
RCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD00NTI0MzhiYS1kNDI5LTQ2NTYtYWNlOS1i
Mjg0NzQ0YmMxNzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t
OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGgg
bWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRo
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0
aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0
aDouMDEwNGluO2hlaWdodDouMDEwNGluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8v
bWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVq
YjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPWUxMDk5Y2E2LWNlNDktNDk5Ny1i
ZGUzLTUzNGQyMjU4MmVlYiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls
eTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_MN2PR00MB068869E4725F8EB1078ED2FDF5A00MN2PR00MB0688namp_--


From nobody Sun May 10 12:58:14 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068E13A0B54 for ; Sun, 10 May 2020 12:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFU0fFvx9CkM for ; Sun, 10 May 2020 12:58:08 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8013A0B6F for ; Sun, 10 May 2020 12:58:07 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id c21so1075894lfb.3 for ; Sun, 10 May 2020 12:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T3UkLd+t960/fzlnfvvTjg82BlcqgedUolm+AF22Ft0=; b=RoOlCNyuJhOl5oGH21SLnHDnoMOnsSZyB9ClfNki2FlbsUKbqAIcWUxzfGSHe2ip6O jY0pSktDn/c7XjODsE0cPu9ukyBpSmz6w4RwudzWsJXxOxFVQ0PF03JFa9D/OuOkoCm0 FNQKIA8twNNHKQbzWlsbUXLYbTM5CRFTCF/mwYU1xp1xEyJs5sWt58JA4O+uJltUoDVm 88KUkkoIqqbF3YOEEY9d9/FCfPM+7IW8Wwc/IYCP5iorG9dlGVFvjRJY8zaE5S4LlUZl gw1bTlKJifIUTVTJZ52/l9upzRjtLlwhTpHh/QS2fyFyEHx7aa+d3vMHSUJwqVUZqMZE Kkzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T3UkLd+t960/fzlnfvvTjg82BlcqgedUolm+AF22Ft0=; b=PUkpJ4o7ycbysXace54XmSaO2+Eulc1PC9QRWTEW0DcsjZ410XQlnjaSoE9yRFW0V8 9HTfSgGagRA5wR8DTQkFH6m5Ek9MbMPFFIPCSMsMy3lsadhuSfvsHb6Zy5bEHZt3/o98 9uQH05j5lwsteBxfShsASE/ELbQdK6HNwdaerQGU96nAdveIDryda/qN+s5qwswm7rWL rkfwo4ATHQQ0NJD8Ye7gagPXdQGPpRB5rbbq4ineMeLcV+UjOlVsYDq2EKYHp1mtgVH3 NKNSlTof1GSWlIASD2fBwo04Ad63MtVjhLco7i+8SRYAVFS4O9oTteulMQC8y84y+iqR Hyog==
X-Gm-Message-State: AOAM533SriWHRXrklTetgTV3GhffM3jPttIsntMB8nCZZaj6IEyQ1rYD Z5GrJDXjyAH/j1iqEtxj3SIj6s2w37UoXBOmLpk=
X-Google-Smtp-Source: ABdhPJzflDWMNrYQs7YK6K16mOQkLo4ndJBatnjWtolppS/nLxbm9SreGeJKjcHxyNf9gMMM4VUd/6hjFiHH4n6ZnTE=
X-Received: by 2002:a19:d:: with SMTP id 13mr8803221lfa.167.1589140685913; Sun, 10 May 2020 12:58:05 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 10 May 2020 12:57:39 -0700
Message-ID: 
To: Mike Jones 
Cc: Torsten Lodderstedt , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000001503b705a550a62b"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 19:58:12 -0000

--0000000000001503b705a550a62b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just as upgrading to OAuth 2.0 from OAuth 1.0 was voluntary, why is
upgrading to OAuth 2.1 not voluntary?

OAuth 2.0 obsoleted OAuth 1.0, just as OAuth 2.1 is obsoleting OAuth 2.1.
Our goal is for new deployments, that are reading the drafts, to use the
best practices.

If existing deployments don't want the advantages of a new version or
extension, there is nobody forcing them to upgrade -- hence my confusion on
your statement that it is "mandatory". Upgrading to OAuth 2.0 from OAuth
1.0 was not mandatory, and some deployments still use OAuth 1.0 today.



=E1=90=A7

On Sun, May 10, 2020 at 12:51 PM Mike Jones 
wrote:

> If I=E2=80=99m not mistaken, the OAuth 2.1 draft is intended to make OAut=
h 2.0
> (RFC 6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC
> 5849) obsolete.  That=E2=80=99s what makes me think developers would view=
 updating
> as mandatory.  If you=E2=80=99re willing to remove the =E2=80=9Creplaces =
6749=E2=80=9D clause from
> the draft, then there would be no perception problem, as it would be clea=
r
> that adoption of 2.1 would be voluntary, just like the other extension
> specs.
>
>
>
> *From:* Dick Hardt 
> *Sent:* Sunday, May 10, 2020 12:38 PM
> *To:* Mike Jones 
> *Cc:* Torsten Lodderstedt ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
> the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
> 2.0 was voluntary.
>
>
>
> Would you clarify why you think upgrading to OAuth 2.1 would be mandatory=
?
>
>
>
>
>
> On Sun, May 10, 2020 at 12:02 PM Mike Jones  40microsoft.com@dmarc.ietf.org> wrote:
>
> I agree with actively maintaining and improving the OAuth 2.0 specs by
> adding enhancements that are voluntary to use.  I=E2=80=99ve worked on ma=
ny such
> improvements, including Dynamic Client Registration, Authorization
> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
> etc.  The issue that=E2=80=99s the subject is the current discussion is w=
hether to
> make use of another enhancement, PKCE, mandatory in cases where it=E2=80=
=99s
> actually not needed, rather than making its use voluntary like the other
> enhancements, which I certainly support.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Torsten Lodderstedt 
> *Sent:* Sunday, May 10, 2020 3:15 AM
> *To:* Mike Jones 
> *Cc:* Daniel Fett ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hi Mike,
>
>
>
> Mike Jones  schrieb am Fr=
.
> 8. Mai 2020 um 18:55:
>
> OAuth 2.1 was supposed to not introduce breaking changes.
>
> I cannot remember the WG met that decision. Can you please refer to the
> respective thread?
>
>
>
> Requiring exact redirect URI matching is already a breaking change. Do yo=
u
> oppose against this as well?
>
>
>
>
>
> If you want to do that, please do it in TxAuth instead.
>
>
>
> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
> force any enhancements/improvements to go into TXAuth? This would cause
> huge migration efforts for existing deployments wanting to benefit from
> those enhancements.
>
>
>
> I think existing deployments are better served by actively maintaining an=
d
> evolving the 2.x line. For example, PAR and RAR are attempts to improve
> OAuth 2.x and make it usable for new use cases. That=E2=80=99s better pro=
tection of
> existing investments than sending them of to TXAuth.
>
> Kind regards,
>
> Torsten.
>
>
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Daniel Fett
> *Sent:* Thursday, May 7, 2020 11:50 PM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> +1 to all what Aaron said. Thanks for pointing this out!
>
>
>
> We need to address this in the security BCP and this will be a normative
> change that affects OpenID Connect Core (just as our current recommendati=
on
> on the usage of nonce).
>
>
>
> We would then have:
>
>
>
> - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE=
,
> except if you are a public client, then you still need PKCE.
>
> - use state, except if you use PKCE, then you don't need state.
>
>
>
> I think there are very good reasons to simplify this down to
>
>
>
> - use PKCE
>
> - you may or may not use state
>
>
>
> First and foremost, not many people will understand why there are cases
> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
> understanding *why* you have to do something is key to compliance. The
> short version "PKCE protects the code; there is a specific case where it =
is
> not needed, but its better to use it all the time" is easy to understand.
> We will not see many implementations following the long version above
> correctly.
>
>
>
> Second, we dramatically reduce technical complexity by reducing cases tha=
t
> need to be handled. We reduce correctness and compliance testing complexi=
ty
> in the same way. We reduce the cost of security analysis, which scales
> really badly to more cases.
>
>
>
> And finally, using nonce to protect against code injection is less robust
> than PKCE. AS have a better track record than clients when it comes to
> correctly implementing security mechanisms.
>
>
>
> Yes, this will make a number of implementations non-spec-compliant, but I
> do not think that this is a huge problem. Software needs to adapt all the
> time and a software that has not been changed in a while is probably not
> one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will g=
et
> there.
>
>
>
> -Daniel
>
>
>
>
>
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>
> Backing up a step or two, there's another point here that I think has bee=
n
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE a=
s
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP fo=
r
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> =E1=90=A7
>

--0000000000001503b705a550a62b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Just as upgrading to OAuth 2.0 from OAuth 1.0 was voluntar=
y, why is upgrading to OAuth 2.1 not voluntary?=C2=A0

OA=
uth 2.0 obsoleted OAuth 1.0, just as OAuth 2.1 is obsoleting OAuth 2.1. Our=
 goal is for new deployments, that are reading the drafts, to use the best =
practices.

If existing deployments don't want th=
e advantages of a new version or extension, there is nobody forcing them to=
 upgrade -- hence my confusion on your statement that it is "mandatory=
". Upgrading to OAuth 2.0 from OAuth 1.0 was not mandatory, and some d=
eployments still use OAuth 1.0 today.



3D""=
=E1=90=A7

On Sun, May 10, 2020 at =
12:51 PM Mike Jones <Mich=
ael.Jones@microsoft.com> wrote:











If I=E2=80=99m no=
t mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0 (RFC 6749) ob=
solete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC 5849) obsolete.=
=C2=A0 That=E2=80=99s what makes me think developers would view
 updating as mandatory.=C2=A0 If you=E2=80=99re willing to remove the =E2=
=80=9Creplaces 6749=E2=80=9D clause from the draft, then there would be no =
perception problem, as it would be clear that adoption of 2.1 would be volu=
ntary, just like the other extension specs.


=C2=A0<=
/u>




From: Dick Hardt <dick.hardt@gmail.com> 

Sent: Sunday, May 10, 2020 12:38 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Torsten Lodderstedt <torsten@lodderstedt.net>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0






Hi Mike, I would consider upgrading to OAuth 2.1 to =
be voluntary, just as the other extensions. Similarly, OAuth 1.0 deployment=
s upgrading to OAuth 2.0 was voluntary.=C2=A0




=C2=A0






Would you clarify why you think upgrading=C2=A0to OA=
uth 2.1 would be mandatory?






=C2=A0






=C2=A0






On Sun, May 10, 2020 at 12:02 PM Mike Jones <Mich=
ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:










I agree with acti=
vely maintaining and improving the OAuth 2.0 specs by adding enhancements t=
hat are voluntary to use.=C2=A0 I=E2=80=99ve worked on many such improvemen=
ts,
 including Dynamic Client Registration, Authorization Metadata, the Device =
Flow, Token Exchange, DPoP, and support PAR and RAR, etc.=C2=A0 The issue t=
hat=E2=80=99s the subject is the current discussion is whether to make use =
of another enhancement, PKCE, mandatory in cases
 where it=E2=80=99s actually not needed, rather than making its use volunta=
ry like the other enhancements, which I certainly support.=



=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Torsten Lodderstedt <torsten=3D40lodderst=
edt.net@dmarc.ietf.org>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>;
oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>




=C2=A0






Hi Mike,








=C2=A0






Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.o=
rg> schrieb am Fr. 8. Mai 2020 um 18:55:










OAuth 2.1 was sup=
posed to not introduce breaking changes.=C2=A0










I cannot remember the WG met that decision. Can you =
please refer to the respective thread?=C2=A0






=C2=A0






Requiring exact redirect URI matching is already a b=
reaking change. Do you oppose against this as well?






=C2=A0






=C2=A0










If you want to do=
 that, please do it in TxAuth instead.










=C2=A0






Interesting statement. Does it mean you want to cons=
erve OAuth 2.0 and force any enhancements/improvements to go into TXAuth? T=
his would cause huge migration efforts for existing
 deployments wanting to benefit from those enhancements.






=C2=A0






I think existing deployments are better served by ac=
tively maintaining and evolving the 2.x line. For example, PAR and RAR are =
attempts to improve OAuth 2.x and make it usable for
 new use cases. That=E2=80=99s better protection of existing investments th=
an sending them of to TXAuth.






Kind regards,






Torsten.






=C2=A0










=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?






=C2=A0




+1 to all what Aaron said. Thanks for pointing this =
out!






=C2=A0






We need to address this in the security BCP and this=
 will be a normative change that affects OpenID Connect Core (just as our c=
urrent recommendation on the usage of nonce).






=C2=A0






We would then have:






=C2=A0






- use PKCE, except if you use OIDC with a nonce, the=
n you don't need PKCE, except if you are a public client, then you stil=
l need PKCE.






- use state, except if you use PKCE, then you don=
9;t need state.






=C2=A0






I think there are very good reasons to simplify this=
 down to







=C2=A0






- use PKCE






- you may or may not use state






=C2=A0






First and foremost, not many people will understand =
why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where they=
 don't. However, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.






=C2=A0






Second, we dramatically reduce technical complexity =
by reducing cases that need to be handled. We reduce correctness and compli=
ance testing complexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.=







=C2=A0






And finally, using nonce to protect against code inj=
ection is less robust than PKCE. AS have a better track record than clients=
 when it comes to correctly implementing security
 mechanisms. 






=C2=A0






Yes, this will make a number of implementations non-=
spec-compliant, but I do not think that this is a huge problem. Software ne=
eds to adapt all the time and a software that has
 not been changed in a while is probably not one you would want to use anyw=
ay. We are setting a new goal for implementations to meet and eventually, m=
aintained implementations will get there.






=C2=A0






-Daniel






=C2=A0






=C2=A0






Am 08.05.20 um 01:38 schrieb Aaron Parecki:










Backing up a step or two, there's another point =
here that I think has been missed in these discussions.





=C2=A0






PKCE solves two problems: stolen authorization codes=
 for public clients, and authorization code injection for all clients. We&#=
39;ve only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.






=C2=A0






The nonce parameter solves authorization code inject=
ion if the client requests an ID token. Public clients using the nonce para=
meter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.






=C2=A0






The only case where OpenID Connect clients don't=
 benefit from PKCE is if they are also confidential clients. Public client =
OIDC clients still need to do PKCE even if they check
 the nonce.






=C2=A0






OpenID Connect servers working with confidential cli=
ents still benefit from PKCE because they can then enforce the authorizatio=
n code injection protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.<=
/u>






=C2=A0






I really don't think it's worth the amount o=
f explanation this will take in the future to write an exception into OAuth=
 2.1 or the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.






=C2=A0






Aaron






=C2=A0








=C2=A0




=C2=A0






On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:










Hello!





=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7










=C2=A0

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0






_______________________________________________

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










=E1=90=A7











--0000000000001503b705a550a62b--


From nobody Sun May 10 13:06:01 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500F23A0B76 for ; Sun, 10 May 2020 13:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhaG3nz5WzGP for ; Sun, 10 May 2020 13:05:44 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C96D3A0B72 for ; Sun, 10 May 2020 13:05:43 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id w7so8341821wre.13 for ; Sun, 10 May 2020 13:05:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DKAH2IgSshKwx2NNiXozYvvfI3spnWUAXrWLm1Tc/tM=; b=JFle2b8GBHMmq6I6jElikLqwmIQ3zc5NyXRkIjz/jUfgzWMvILDif/1EysC+JIhrOu BikbE5liVKmWZO37EK6f7vU5oYUiPrbJXSiLu51EVv9OPeoZ62tqYB1ieTlmaf2bnH51 kkqjQcnweWb6fs4XTG4pR8fgy2HtiIHgPDFrs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DKAH2IgSshKwx2NNiXozYvvfI3spnWUAXrWLm1Tc/tM=; b=rGsyfRD1+1sOXHeOTX4Qe5nzVsXqOMDYh5yAED8gtsHn0v5WYDGiShgT5Dh4s3qQY3 7B8+MKH32ZrZm0a9HjfgMcS/78lDMoHKLFzbsSNEpt4aIJHF0/IiftWIhdIBAuJfbyjY 983/uwZi3gNVd+gceTHzB8JIwMIUs6JMwaeiM7KqH3ixWA6JvyHNkTmral0+AnVugmTS AfDmKVAR12aoZ6FNue660P+qz2+U7IbBBUPccE2LbOInErJ3VUW9tDxHKvDQnhrrmquG nke3u6/WTCpjRz0qXLRpwe0iNc6XEToYuZVkgltSxb8Xt9A35/hxCZMFrsS1G82VOCY2 Iz8Q==
X-Gm-Message-State: AGi0PuYyroGMJF3WI97J8cIXAKHoVXB2BpFpaV6iNzbgfafXMgUAWamS eWpyVJNRNdhLok0Yurnxm5TY+g==
X-Google-Smtp-Source: APiQypIkuJaVn1IllATnLns1AD115iwdSQklrTblUdyP4FV8MvUbH0XarqUDINF+FoQqwZ7j0rl1xg==
X-Received: by 2002:a5d:54c4:: with SMTP id x4mr15816473wrv.73.1589141141464;  Sun, 10 May 2020 13:05:41 -0700 (PDT)
Received: from [10.0.0.2] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id b22sm31249664wmj.1.2020.05.10.13.05.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2020 13:05:40 -0700 (PDT)
From: Neil Madden 
Message-Id: <1C5C5CA8-D414-4507-BAFF-0D7ACFA24005@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2273C551-1D91-442C-95C4-05B01B5107A4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 10 May 2020 21:05:39 +0100
In-Reply-To: 
Cc: Mike Jones , "oauth@ietf.org" , Torsten Lodderstedt 
To: Dick Hardt 
References:    
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:05:56 -0000

--Apple-Mail=_2273C551-1D91-442C-95C4-05B01B5107A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

But if an AS upgrades to OAuth 2.1 then it MUST reject authorization =
requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), =
so this will only be possible when all clients support PKCE.

This makes it impossible for a 2.1-compliant AS to also support non-PKCE =
2.0 clients (i.e., the vast majority of them).

I think we can have a 2.1 spec that says clients and servers MUST =
support PKCE without this hard-fail clause. Otherwise I can=E2=80=99t =
see how we=E2=80=99d ever ship with 2.1-compliance enabled =
out-of-the-box.

=E2=80=94 Neil

> On 10 May 2020, at 20:38, Dick Hardt  wrote:
>=20
> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just =
as the other extensions. Similarly, OAuth 1.0 deployments upgrading to =
OAuth 2.0 was voluntary.=20
>=20
> Would you clarify why you think upgrading to OAuth 2.1 would be =
mandatory?
>=20
>=20
> On Sun, May 10, 2020 at 12:02 PM Mike Jones =
> wrote:
> I agree with actively maintaining and improving the OAuth 2.0 specs by =
adding enhancements that are voluntary to use.  I=E2=80=99ve worked on =
many such improvements, including Dynamic Client Registration, =
Authorization Metadata, the Device Flow, Token Exchange, DPoP, and =
support PAR and RAR, etc.  The issue that=E2=80=99s the subject is the =
current discussion is whether to make use of another enhancement, PKCE, =
mandatory in cases where it=E2=80=99s actually not needed, rather than =
making its use voluntary like the other enhancements, which I certainly =
support.
>=20
> =20
>=20
>                                                        -- Mike
>=20
> =20
>=20
> From: Torsten Lodderstedt >=20
> Sent: Sunday, May 10, 2020 3:15 AM
> To: Mike Jones >
> Cc: Daniel Fett >; =
oauth@ietf.org 
> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>=20
> =20
>=20
> Hi Mike,
>=20
> =20
>=20
> Mike Jones > schrieb am Fr. 8. Mai 2020 um =
18:55:
>=20
> OAuth 2.1 was supposed to not introduce breaking changes.=20
>=20
> I cannot remember the WG met that decision. Can you please refer to =
the respective thread?=20
>=20
> =20
>=20
> Requiring exact redirect URI matching is already a breaking change. Do =
you oppose against this as well?
>=20
> =20
>=20
> =20
>=20
> If you want to do that, please do it in TxAuth instead.
>=20
> =20
>=20
> Interesting statement. Does it mean you want to conserve OAuth 2.0 and =
force any enhancements/improvements to go into TXAuth? This would cause =
huge migration efforts for existing deployments wanting to benefit from =
those enhancements.
>=20
> =20
>=20
> I think existing deployments are better served by actively maintaining =
and evolving the 2.x line. For example, PAR and RAR are attempts to =
improve OAuth 2.x and make it usable for new use cases. That=E2=80=99s =
better protection of existing investments than sending them of to =
TXAuth.
>=20
> Kind regards,
>=20
> Torsten.
>=20
> =20
>=20
> =20
>=20
>                                                        -- Mike
>=20
> =20
>=20
> From: OAuth > =
On Behalf Of Daniel Fett
> Sent: Thursday, May 7, 2020 11:50 PM
> To: oauth@ietf.org 
> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>=20
> =20
>=20
> +1 to all what Aaron said. Thanks for pointing this out!
>=20
> =20
>=20
> We need to address this in the security BCP and this will be a =
normative change that affects OpenID Connect Core (just as our current =
recommendation on the usage of nonce).
>=20
> =20
>=20
> We would then have:
>=20
> =20
>=20
> - use PKCE, except if you use OIDC with a nonce, then you don't need =
PKCE, except if you are a public client, then you still need PKCE.
>=20
> - use state, except if you use PKCE, then you don't need state.
>=20
> =20
>=20
> I think there are very good reasons to simplify this down to
>=20
> =20
>=20
> - use PKCE
>=20
> - you may or may not use state
>=20
> =20
>=20
> First and foremost, not many people will understand why there are =
cases when the BCP/OAuth 2.1 mandate PKCE and some where they don't. =
However, understanding why you have to do something is key to =
compliance. The short version "PKCE protects the code; there is a =
specific case where it is not needed, but its better to use it all the =
time" is easy to understand. We will not see many implementations =
following the long version above correctly.
>=20
> =20
>=20
> Second, we dramatically reduce technical complexity by reducing cases =
that need to be handled. We reduce correctness and compliance testing =
complexity in the same way. We reduce the cost of security analysis, =
which scales really badly to more cases.
>=20
> =20
>=20
> And finally, using nonce to protect against code injection is less =
robust than PKCE. AS have a better track record than clients when it =
comes to correctly implementing security mechanisms.
>=20
> =20
>=20
> Yes, this will make a number of implementations non-spec-compliant, =
but I do not think that this is a huge problem. Software needs to adapt =
all the time and a software that has not been changed in a while is =
probably not one you would want to use anyway. We are setting a new goal =
for implementations to meet and eventually, maintained implementations =
will get there.
>=20
> =20
>=20
> -Daniel
>=20
> =20
>=20
> =20
>=20
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>=20
> Backing up a step or two, there's another point here that I think has =
been missed in these discussions.
>=20
> =20
>=20
> PKCE solves two problems: stolen authorization codes for public =
clients, and authorization code injection for all clients. We've only =
been talking about authorization code injection on the list so far. The =
quoted section of the security BCP (4.5.3) which says clients can do =
PKCE or use the nonce, is only talking about preventing authorization =
code injection.
>=20
> =20
>=20
> The nonce parameter solves authorization code injection if the client =
requests an ID token. Public clients using the nonce parameter are still =
susceptible to stolen authorization codes so they still need to do PKCE =
as well.
>=20
> =20
>=20
> The only case where OpenID Connect clients don't benefit from PKCE is =
if they are also confidential clients. Public client OIDC clients still =
need to do PKCE even if they check the nonce.
>=20
> =20
>=20
> OpenID Connect servers working with confidential clients still benefit =
from PKCE because they can then enforce the authorization code injection =
protection server-side rather than cross their fingers that clients =
implemented the nonce check properly.
>=20
> =20
>=20
> I really don't think it's worth the amount of explanation this will =
take in the future to write an exception into OAuth 2.1 or the Security =
BCP for only some types of OpenID Connect clients when all clients would =
benefit from PKCE anyway.
>=20
> =20
>=20
> Aaron
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt > wrote:
>=20
> Hello!
>=20
> =20
>=20
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is =
best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as the nonce solves some of the issues that PKCE protects against. We =
think that most OpenID Connect implementations also support OAuth 2.0, =
and hence have support for PKCE if following best practices.
>=20
> =20
>=20
> The advantages or requiring PKCE are:
>=20
> =20
>=20
> - a simpler programming model across all OAuth applications and =
profiles as they all use PKCE
>=20
> =20
>=20
> - reduced attack surface when using  S256 as a fingerprint of the =
verifier is sent through the browser instead of the clear text value
>=20
> =20
>=20
> - enforcement by AS not client - makes it easier to handle for client =
developers and AS can ensure the check is conducted
>=20
> =20
>=20
> What are disadvantages besides the potential impact to OpenID Connect =
deployments? How significant is that impact?
>=20
> =20
>=20
> Dick, Aaron, and Torsten
>=20
> =20
>=20
> =E1=90=A7
>=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 =

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


--Apple-Mail=_2273C551-1D91-442C-95C4-05B01B5107A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

But =
if an AS upgrades to OAuth 2.1 then it MUST reject authorization =
requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), =
so this will only be possible when all clients support PKCE.

This makes it impossible =
for a 2.1-compliant AS to also support non-PKCE 2.0 clients (i.e., the =
vast majority of them).

I think we can have a 2.1 spec =
that says clients and servers MUST support PKCE without this hard-fail =
clause. Otherwise I can=E2=80=99t see how we=E2=80=99d ever ship with =
2.1-compliance enabled out-of-the-box.

=E2=80=94 Neil

On 10 May 2020, at 20:38, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Mike, I would consider =
upgrading to OAuth 2.1 to be voluntary, just as the other extensions. =
Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0 was =
voluntary. 

Would=
 you clarify why you think upgrading to OAuth 2.1 would be =
mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones =
<Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:









I =
agree with actively maintaining and improving the OAuth 2.0 specs by =
adding enhancements that are voluntary to use.  I=E2=80=99ve worked =
on many such improvements, including Dynamic Client Registration, =
Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and =
RAR, etc.  The issue that=E2=80=99s the subject is the current =
discussion is whether to make use of another enhancement, PKCE, =
mandatory in cases where it=E2=80=99s actually not needed, rather than =
making
 its use voluntary like the other enhancements, which I certainly =
support.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 


From: Torsten Lodderstedt =
<torsten=3D40lodderstedt.net@dmarc.ietf.org>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require =
PKCE?


 




Hi Mike,






 




Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> schrieb am Fr. 8. Mai =
2020 um 18:55:








OAuth 2.1 was supposed to not introduce breaking =
changes. 








I cannot remember the WG met that =
decision. Can you please refer to the respective thread? 




 




Requiring exact redirect URI =
matching is already a breaking change. Do you oppose against this as =
well?




 




 








If you want to do that, please do it in TxAuth =
instead.








 




Interesting statement. Does it =
mean you want to conserve OAuth 2.0 and force any =
enhancements/improvements to go into TXAuth? This would cause huge =
migration efforts for existing deployments wanting to benefit from those =
enhancements.




 




I think existing deployments are =
better served by actively maintaining and evolving the 2.x line. For =
example, PAR and RAR are attempts to improve OAuth 2.x and make it =
usable for new use cases. That=E2=80=99s better protection of existing =
investments
 than sending them of to TXAuth.




Kind regards,




Torsten.




 








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




From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




 


+1 to all what Aaron said. Thanks =
for pointing this out!




 




We need to address this in the =
security BCP and this will be a normative change that affects OpenID =
Connect Core (just as our current recommendation on the usage of =
nonce).




 




We would then have:




 




- use PKCE, except if you use =
OIDC with a nonce, then you don't need PKCE, except if you are a public =
client, then you still need PKCE.




- use state, except if you use =
PKCE, then you don't need state.




 




I think there are very good =
reasons to simplify this down to





 




- use PKCE




- you may or may not use state




 




First and foremost, not many =
people will understand why there are cases when the BCP/OAuth 2.1 =
mandate PKCE and some where they don't. However, understanding
why you have to do something is key to compliance. The =
short version "PKCE protects the code; there is a specific case where it =
is not needed, but its better to use it all the time" is easy to =
understand. We will not see many implementations following
 the long version above correctly.
=




 




Second, we dramatically reduce =
technical complexity by reducing cases that need to be handled. We =
reduce correctness and compliance testing complexity in the same way. We =
reduce
 the cost of security analysis, which scales really badly to more =
cases.




 




And finally, using nonce to =
protect against code injection is less robust than PKCE. AS have a =
better track record than clients when it comes to correctly implementing =
security
 mechanisms. 




 




Yes, this will make a number of =
implementations non-spec-compliant, but I do not think that this is a =
huge problem. Software needs to adapt all the time and a software that =
has
 not been changed in a while is probably not one you would want to use =
anyway. We are setting a new goal for implementations to meet and =
eventually, maintained implementations will get there.




 




-Daniel




 




 




Am 08.05.20 um 01:38 schrieb =
Aaron Parecki:








Backing up a step or two, there's =
another point here that I think has been missed in these discussions.



 




PKCE solves two problems: stolen =
authorization codes for public clients, and authorization code injection =
for all clients. We've only been talking about authorization code =
injection
 on the list so far. The quoted section of the security BCP (4.5.3) =
which says clients can do PKCE or use the nonce, is only talking about =
preventing authorization code injection.




 




The nonce parameter solves =
authorization code injection if the client requests an ID token. Public =
clients using the nonce parameter are still susceptible to stolen =
authorization
 codes so they still need to do PKCE as well.




 




The only case where OpenID =
Connect clients don't benefit from PKCE is if they are also confidential =
clients. Public client OIDC clients still need to do PKCE even if they =
check
 the nonce.




 




OpenID Connect servers working =
with confidential clients still benefit from PKCE because they can then =
enforce the authorization code injection protection =
server-side rather than
 cross their fingers that clients implemented the nonce check =
properly.




 




I really don't think it's worth =
the amount of explanation this will take in the future to write an =
exception into OAuth 2.1 or the Security BCP for only some types of =
OpenID Connect
 clients when all clients would benefit from PKCE anyway.




 




Aaron




 






 


 




On Wed, May 6, 2020 at 10:48 AM =
Dick Hardt <dick.hardt@gmail.com> wrote:








Hello!



 




We would like to have PKCE be a =
MUST in OAuth 2.1 code flows. This is best practice for OAuth 2.0. It is =
not common in OpenID Connect servers as the nonce solves some of the =
issues
 that PKCE protects against. We think that most OpenID Connect =
implementations also support OAuth 2.0, and hence have support for =
PKCE if following best practices.




 




The advantages or requiring PKCE =
are:




 




- a simpler programming model =
across all OAuth applications and profiles as they all use PKCE




 




- reduced attack surface when =
using  S256 as a fingerprint of the verifier is sent through the =
browser instead of the clear text value




 




- enforcement by AS not client - =
makes it easier to handle for client developers and AS can ensure the =
check is conducted




 




What are disadvantages besides =
the potential impact to OpenID Connect deployments? How significant is =
that impact?




 




Dick, Aaron, and Torsten




 








=E1=90=A7








 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


 




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


3D""=E1=90=A7

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

=

--Apple-Mail=_2273C551-1D91-442C-95C4-05B01B5107A4--


From nobody Sun May 10 13:14:59 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94D63A0B7D; Sun, 10 May 2020 13:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS6hoghrGfcH; Sun, 10 May 2020 13:14:55 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15A23A0B7C; Sun, 10 May 2020 13:14:54 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id o10so6104313ejn.10; Sun, 10 May 2020 13:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i2+LLcDtwAdbRZ4bfBbom3nOYpICMCjlODBzBaPGrBY=; b=EVkPx/zQqVawTTYTIygZffgDzzMQRPsvhfC96BlCscWA++q6lLlbT+UXBOmWdnnkRp nBil4Awen/y8yxNA6iuYAZ3YxFqwlLbaOilyKoEvK+TkpDaj+Cssro2pOWbGLBisqZrg HKTDnr2Q/vkIYImcFQlRzdhp3Klr4JA2CoUYsY2KOh1W/xGjN6Dxh3lLHi1bS6hf19Do seIt6WIKuafWRex+JujRaNgdYXIx0P3Mz06g/sSWQtvEkuJrq5JFcVmlQTsusaCNuJun HDrF7zBgMksJXs/eNLxIa5te8qdKyvPJiTC7IC7JjNZFwI7yVfxz0pzfUE8m2/9WT2ps R2bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i2+LLcDtwAdbRZ4bfBbom3nOYpICMCjlODBzBaPGrBY=; b=T/KjnF5lDM8oymE4bysYEVrtetqyJtgqu8REvPa//1fdHDb7s5Ry1BuJSpXc2rcYpk TfzOqPPuPM1ytlcLVM8+Z2D8fbzx2IHUmteyOUr0aMsLbYRo0G9KAGB+EDD7oncbFaqu w0dOJEz6wZv4Lz/EeVhupu7t0xeF4w68TLzI4mCWQe0Fk09Npd/f2nmx5x7Fmdve3yA8 5w0JdkdmRoQKmrAEJxujpSDncobGAWYAm+sNv/sZBSKNYLXRUfYbM3NLnRT4Q72/+MUJ RoyNASq0zmqPccW9Pvi2tS0BMqUN5mGlvp8pAe4B39d463pY39HncuaW5zkjpcg1a1m0 dgFA==
X-Gm-Message-State: AGi0Pub3/kkhjinqbyEjZY85L3IxLf2SCUJ9zJKnIw7EWM2shzTjgsXA cSdBEIddWAVut12oiD+Xi3chLlGG2pVdupZi229oES4Houk=
X-Google-Smtp-Source: APiQypJPTUhOLOjlTH+1BIQmTCTzZYnVJsHuzb/tDXYusE2JRFpLs05lbuTSb2VCP9+sI1oBP7nV+/yDdWn0mKi3nLU=
X-Received: by 2002:a17:907:4420:: with SMTP id om24mr9975521ejb.99.1589141693083;  Sun, 10 May 2020 13:14:53 -0700 (PDT)
MIME-Version: 1.0
References: <033601d622f0$7869bfa0$693d3ee0$@augustcellars.com>
In-Reply-To: <033601d622f0$7869bfa0$693d3ee0$@augustcellars.com>
From: Jared Jennings 
Date: Sun, 10 May 2020 15:14:40 -0500
Message-ID: 
To: Jim Schaad 
Cc: oauth , draft-ietf-ace-oauth-authz@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001d34f605a550e2ed"
Archived-At: 
Subject: Re: [OAUTH-WG] Refreshing tokens on the RS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:14:57 -0000

--0000000000001d34f605a550e2ed
Content-Type: text/plain; charset="UTF-8"

Not exactly the same, but seems similar to some of the proposed logic in
https://tools.ietf.org/wg/oauth/draft-ietf-oauth-incremental-authz/

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Tue, May 5, 2020 at 10:19 AM Jim Schaad  wrote:

> Over in the ACE working group we are currently having a discussion about
> refreshing tokens on an RS.  I want to make sure that this is not something
> that this working group has already solved.  The basic scenario is:
>
> 1.  Client gets token T1 and posts it to the RS
> 2.  After some time the RS returns and error to the client about an access
> issue
> 3.  Client gets a new token from the AS T2, possibly using a refresh token.
> 4. Client posts the token T2 to the RS
> 5.  The RS somehow needs to associate token T1 and T2 for long term
> security
> sessions.
>
> I do not believe that OAuth has this issue because there is not currently
> any concept that a token is used for anything other than a single
> request/response between the client and the RS.  There is no idea of the RS
> storing tokens long term associated with a TLS session that might need to
> have the access rights for that TLS session changed.
>
> Please provide any feedback that you might have.
>
> Thanks
> Jim
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000001d34f605a550e2ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Not exactly the same, but seems similar to some of the pro=
posed logic in=C2=A0https://tools.ietf.org/wg/oauth/draft-ietf-oauth-i=
ncremental-authz/

-=
Jared
Skype:jaredljennings
Signal:+1 816.730.9540<=
/div>
WhatsApp:=C2=A0+1 816.678.4152

<=
/div>

On Tue, May 5, 2020 at 10:19 AM Jim Schaad <ietf@augustcellars.com> wrote:
Over in the ACE working group we a=
re currently having a discussion about

refreshing tokens on an RS.=C2=A0 I want to make sure that this is not some=
thing

that this working group has already solved.=C2=A0 The basic scenario is:


1.=C2=A0 Client gets token T1 and posts it to the RS

2.=C2=A0 After some time the RS returns and error to the client about an ac=
cess

issue

3.=C2=A0 Client gets a new token from the AS T2, possibly using a refresh t=
oken.

4. Client posts the token T2 to the RS

5.=C2=A0 The RS somehow needs to associate token T1 and T2 for long term se=
curity

sessions.



I do not believe that OAuth has this issue because there is not currently
any concept that a token is used for anything other than a single

request/response between the client and the RS.=C2=A0 There is no idea of t=
he RS

storing tokens long term associated with a TLS session that might need to
have the access rights for that TLS session changed.



Please provide any feedback that you might have.



Thanks

Jim





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000001d34f605a550e2ed--


From nobody Sun May 10 13:20:22 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8873A0B8D for ; Sun, 10 May 2020 13:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhFhZJN33DRk for ; Sun, 10 May 2020 13:19:58 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47083A0B88 for ; Sun, 10 May 2020 13:19:57 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id z22so5730997lfd.0 for ; Sun, 10 May 2020 13:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rxWKOT8XrvHeIx0OrwaLYycV6SaNJFvB6orGeLzucK8=; b=llnDoVu8mVL/XDh2JxaB+6pBH3q3r3bn4cN1NVyqv1qqoSXyMA6sW/aheRyvZIKbkq lyblejwielQ+twguwy3ZBE9M4T+7bGEyVx2SLzKiWHmWNXSSXvv+7c0SpdLk2UnzBCSB W9oe05vja9dLanPE8gLD7tV2jVL2aAJF2gJ4lAvNmpllPxVjPZjL8kzeuIT7/wCJ6dgi hJUYYevl3mw0kXgIZJnwBrCFAPfSLzTvb6oQYwDnq+IwqXKub8/QB6vxHooKR6d7nmbU 9+4DUukB2rMjYlc1CqH0bvEpuNKozROQv7tcjtpj2WrZPpcGcKLrQ5WJFfDZmKCPWkoV 6qDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rxWKOT8XrvHeIx0OrwaLYycV6SaNJFvB6orGeLzucK8=; b=YnWV8R/+UMQdb0Y07s4CyU+zmDC7ZR1tlte6FfpOBk93GbEGnT2/PRuVDunpiXuP7n Ejuho1gD4rUO5GavlO2xwHOGI/nGOPjF1P0PBGvs6NjhKi7giLrwBlr3kGq8tC99Y37Y BiCplDyskO+li5OroYZJ8NwKLsxP7NCT3oZXv5HR2GDoB4129BgnzP1bwZBlKrdI0+Wr pHuaiKY3IQ6IjCzqkDxm3SMb69AhWcLFHV5nDGbyMcwThq0Ehp+uqdXGrVn/o2z38wS4 gHquMbq9etj3ioaOGAALHb5ouMw/7hXWM2PzXMuDjOlE3obn0Em52koPGrU06FnXk/Ft MG4w==
X-Gm-Message-State: AOAM530pOrlDNF+6MlGRuG9ei4AKMpWuT45VcwsvXTOuoygN8GCOLlof 1y3gmS6Y0YRMEojCKNONS2Q62ZY8wXV2tAw8A1U=
X-Google-Smtp-Source: ABdhPJyod/p3e/27G842/uKlaflEZrAjP7C7vxHuC3j+1mWr/RwoKrAlfojwzhNBi4PIqo2VZr9Z+S/l3U6Ft8l6aBY=
X-Received: by 2002:a19:d:: with SMTP id 13mr8845172lfa.167.1589141995858; Sun, 10 May 2020 13:19:55 -0700 (PDT)
MIME-Version: 1.0
References:     <1C5C5CA8-D414-4507-BAFF-0D7ACFA24005@forgerock.com>
In-Reply-To: <1C5C5CA8-D414-4507-BAFF-0D7ACFA24005@forgerock.com>
From: Dick Hardt 
Date: Sun, 10 May 2020 13:19:29 -0700
Message-ID: 
To: Neil Madden 
Cc: Mike Jones ,  "oauth@ietf.org" ,  Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary="00000000000029350c05a550f4de"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 20:20:03 -0000

--00000000000029350c05a550f4de
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Is there a reason why a server can not support both OAuth 2.0 and OAuth
2.1? The version supported could be dependent on the client id, ie older
clients could still be OAuth 2.0, and newer clients would be OAuth 2.1, and
PKCE would be enforced.
=E1=90=A7

On Sun, May 10, 2020 at 1:05 PM Neil Madden 
wrote:

> But if an AS upgrades to OAuth 2.1 then it MUST reject authorization
> requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), s=
o this
> will only be possible when all clients support PKCE.
>
> This makes it impossible for a 2.1-compliant AS to also support non-PKCE
> 2.0 clients (i.e., the vast majority of them).
>
> I think we can have a 2.1 spec that says clients and servers MUST support
> PKCE without this hard-fail clause. Otherwise I can=E2=80=99t see how we=
=E2=80=99d ever
> ship with 2.1-compliance enabled out-of-the-box.
>
> =E2=80=94 Neil
>
> On 10 May 2020, at 20:38, Dick Hardt  wrote:
>
> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
> the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
> 2.0 was voluntary.
>
> Would you clarify why you think upgrading to OAuth 2.1 would be mandatory=
?
>
>
> On Sun, May 10, 2020 at 12:02 PM Mike Jones  40microsoft.com@dmarc.ietf.org> wrote:
>
>> I agree with actively maintaining and improving the OAuth 2.0 specs by
>> adding enhancements that are voluntary to use.  I=E2=80=99ve worked on m=
any such
>> improvements, including Dynamic Client Registration, Authorization
>> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR=
,
>> etc.  The issue that=E2=80=99s the subject is the current discussion is =
whether to
>> make use of another enhancement, PKCE, mandatory in cases where it=E2=80=
=99s
>> actually not needed, rather than making its use voluntary like the other
>> enhancements, which I certainly support.
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Torsten Lodderstedt 
>> *Sent:* Sunday, May 10, 2020 3:15 AM
>> *To:* Mike Jones 
>> *Cc:* Daniel Fett ; oauth@ietf.org
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> Hi Mike,
>>
>>
>>
>> Mike Jones  schrieb am F=
r.
>> 8. Mai 2020 um 18:55:
>>
>> OAuth 2.1 was supposed to not introduce breaking changes.
>>
>> I cannot remember the WG met that decision. Can you please refer to the
>> respective thread?
>>
>>
>>
>> Requiring exact redirect URI matching is already a breaking change. Do
>> you oppose against this as well?
>>
>>
>>
>>
>>
>> If you want to do that, please do it in TxAuth instead.
>>
>>
>>
>> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
>> force any enhancements/improvements to go into TXAuth? This would cause
>> huge migration efforts for existing deployments wanting to benefit from
>> those enhancements.
>>
>>
>>
>> I think existing deployments are better served by actively maintaining
>> and evolving the 2.x line. For example, PAR and RAR are attempts to impr=
ove
>> OAuth 2.x and make it usable for new use cases. That=E2=80=99s better pr=
otection of
>> existing investments than sending them of to TXAuth.
>>
>> Kind regards,
>>
>> Torsten.
>>
>>
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Daniel Fett
>> *Sent:* Thursday, May 7, 2020 11:50 PM
>> *To:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>>
>>
>>
>> +1 to all what Aaron said. Thanks for pointing this out!
>>
>>
>>
>> We need to address this in the security BCP and this will be a normative
>> change that affects OpenID Connect Core (just as our current recommendat=
ion
>> on the usage of nonce).
>>
>>
>>
>> We would then have:
>>
>>
>>
>> - use PKCE, except if you use OIDC with a nonce, then you don't need
>> PKCE, except if you are a public client, then you still need PKCE.
>>
>> - use state, except if you use PKCE, then you don't need state.
>>
>>
>>
>> I think there are very good reasons to simplify this down to
>>
>>
>>
>> - use PKCE
>>
>> - you may or may not use state
>>
>>
>>
>> First and foremost, not many people will understand why there are cases
>> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
>> understanding *why* you have to do something is key to compliance. The
>> short version "PKCE protects the code; there is a specific case where it=
 is
>> not needed, but its better to use it all the time" is easy to understand=
.
>> We will not see many implementations following the long version above
>> correctly.
>>
>>
>>
>> Second, we dramatically reduce technical complexity by reducing cases
>> that need to be handled. We reduce correctness and compliance testing
>> complexity in the same way. We reduce the cost of security analysis, whi=
ch
>> scales really badly to more cases.
>>
>>
>>
>> And finally, using nonce to protect against code injection is less robus=
t
>> than PKCE. AS have a better track record than clients when it comes to
>> correctly implementing security mechanisms.
>>
>>
>>
>> Yes, this will make a number of implementations non-spec-compliant, but =
I
>> do not think that this is a huge problem. Software needs to adapt all th=
e
>> time and a software that has not been changed in a while is probably not
>> one you would want to use anyway. We are setting a new goal for
>> implementations to meet and eventually, maintained implementations will =
get
>> there.
>>
>>
>>
>> -Daniel
>>
>>
>>
>>
>>
>> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>>
>> Backing up a step or two, there's another point here that I think has
>> been missed in these discussions.
>>
>>
>>
>> PKCE solves two problems: stolen authorization codes for public clients,
>> and authorization code injection for all clients. We've only been talkin=
g
>> about authorization code injection on the list so far. The quoted sectio=
n
>> of the security BCP (4.5.3) which says clients can do PKCE or use the
>> nonce, is only talking about preventing authorization code injection.
>>
>>
>>
>> The nonce parameter solves authorization code injection if the client
>> requests an ID token. Public clients using the nonce parameter are still
>> susceptible to stolen authorization codes so they still need to do PKCE =
as
>> well.
>>
>>
>>
>> The only case where OpenID Connect clients don't benefit from PKCE is if
>> they are also confidential clients. Public client OIDC clients still nee=
d
>> to do PKCE even if they check the nonce.
>>
>>
>>
>> OpenID Connect servers working with confidential clients still benefit
>> from PKCE because they can then enforce the authorization code injection
>> protection server-side rather than cross their fingers that clients
>> implemented the nonce check properly.
>>
>>
>>
>> I really don't think it's worth the amount of explanation this will take
>> in the future to write an exception into OAuth 2.1 or the Security BCP f=
or
>> only some types of OpenID Connect clients when all clients would benefit
>> from PKCE anyway.
>>
>>
>>
>> Aaron
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>>
>> Hello!
>>
>>
>>
>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is
>> best practice for OAuth 2.0. It is not common in OpenID Connect servers =
as
>> the nonce solves some of the issues that PKCE protects against. We think
>> that most OpenID Connect implementations also support OAuth 2.0, and
>> hence have support for PKCE if following best practices.
>>
>>
>>
>> The advantages or requiring PKCE are:
>>
>>
>>
>> - a simpler programming model across all OAuth applications and profiles
>> as they all use PKCE
>>
>>
>>
>> - reduced attack surface when using  S256 as a fingerprint of the
>> verifier is sent through the browser instead of the clear text value
>>
>>
>>
>> - enforcement by AS not client - makes it easier to handle for client
>> developers and AS can ensure the check is conducted
>>
>>
>>
>> What are disadvantages besides the potential impact to OpenID Connect
>> deployments? How significant is that impact?
>>
>>
>>
>> Dick, Aaron, and Torsten
>>
>>
>>
>> =E1=90=A7
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> =E1=90=A7
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--00000000000029350c05a550f4de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Is there a reason why a server can not support both OAuth =
2.0 and OAuth 2.1? The version supported could be dependent=C2=A0on the cli=
ent id, ie older clients could still be OAuth 2.0, and newer clients would =
be OAuth 2.1, and PKCE would be enforced.
3D""=E1=90=A7
On =
Sun, May 10, 2020 at 1:05 PM Neil Madden <neil.madden@forgerock.com> wrote:
But if an AS upgrades to OAuth 2.1 then it MUST reject authorization=
 requests that don=E2=80=99t include a code_challenge (section 4.1.2.1), so=
 this will only be possible when all clients support PKCE.

This makes it impossible for a 2.1-compliant AS to also support non-PKCE=
 2.0 clients (i.e., the vast majority of them).

I think we can have a 2.1 spec that says clients and servers MUST support =
PKCE without this hard-fail clause. Otherwise I can=E2=80=99t see how we=E2=
=80=99d ever ship with 2.1-compliance enabled out-of-the-box.
=E2=80=94 Neil

On 10 May 2020, at 20:38, Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Mike, I would consider upgradin=
g to OAuth 2.1 to be voluntary, just as the other extensions. Similarly, OA=
uth 1.0 deployments upgrading to OAuth 2.0 was voluntary.=C2=A0

Would you clarify why you think upgrading=C2=A0to OAuth 2.1 would b=
e mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jone=
s <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:









I agree with=
 actively maintaining and improving the OAuth 2.0 specs by adding enhanceme=
nts that are voluntary to use.=C2=A0 I=E2=80=99ve worked on many such impro=
vements, including Dynamic Client Registration, Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR, =
etc.=C2=A0 The issue that=E2=80=99s the subject is the current discussion i=
s whether to make use of another enhancement, PKCE, mandatory in cases wher=
e it=E2=80=99s actually not needed, rather than making
 its use voluntary like the other enhancements, which I certainly support.<=
u>
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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>
=C2=A0<=
u>


=
From: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org<=
/a>>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>


=C2=A0




Hi Mike,






=C2=A0




Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.i=
etf.org> schrieb am Fr. 8. Mai 2020 um 18:55:








OAuth 2.1 wa=
s supposed to not introduce breaking changes.=C2=A0







I cannot remember the WG met that decision. Can=
 you please refer to the respective thread?=C2=A0




=C2=A0




Requiring exact redirect URI matching is alread=
y a breaking change. Do you oppose against this as well?




=C2=A0




=C2=A0








If you want =
to do that, please do it in TxAuth instead.








=C2=A0




Interesting statement. Does it mean you want to=
 conserve OAuth 2.0 and force any enhancements/improvements to go into TXAu=
th? This would cause huge migration efforts for existing deployments wantin=
g to benefit from those enhancements.




=C2=A0




I think existing deployments are better served =
by actively maintaining and evolving the 2.x line. For example, PAR and RAR=
 are attempts to improve OAuth 2.x and make it usable for new use cases. Th=
at=E2=80=99s better protection of existing investments
 than sending them of to TXAuth.




Kind regards,




Torsten.




=C2=A0








=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?




=C2=A0


+1 to all what Aaron said. Thanks for pointing =
this out!




=C2=A0




We need to address this in the security BCP and=
 this will be a normative change that affects OpenID Connect Core (just as =
our current recommendation on the usage of nonce).




=C2=A0




We would then have:




=C2=A0




- use PKCE, except if you use OIDC with a nonce=
, then you don't need PKCE, except if you are a public client, then you=
 still need PKCE.




- use state, except if you use PKCE, then you d=
on't need state.




=C2=A0




I think there are very good reasons to simplify=
 this down to





=C2=A0




- use PKCE




- you may or may not use state



=C2=A0




First and foremost, not many people will unders=
tand why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where=
 they don't. However, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.




=C2=A0




Second, we dramatically reduce technical comple=
xity by reducing cases that need to be handled. We reduce correctness and c=
ompliance testing complexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.=





=C2=A0




And finally, using nonce to protect against cod=
e injection is less robust than PKCE. AS have a better track record than cl=
ients when it comes to correctly implementing security
 mechanisms. 




=C2=A0




Yes, this will make a number of implementations=
 non-spec-compliant, but I do not think that this is a huge problem. Softwa=
re needs to adapt all the time and a software that has
 not been changed in a while is probably not one you would want to use anyw=
ay. We are setting a new goal for implementations to meet and eventually, m=
aintained implementations will get there.




=C2=A0




-Daniel




=C2=A0




=C2=A0




Am 08.05.20 um 01:38 schrieb Aaron Parecki:<=
/u>








Backing up a step or two, there's another p=
oint here that I think has been missed in these discussions.



=C2=A0




PKCE solves two problems: stolen authorization =
codes for public clients, and authorization code injection for all clients.=
 We've only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.




=C2=A0




The nonce parameter solves authorization code i=
njection if the client requests an ID token. Public clients using the nonce=
 parameter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.




=C2=A0




The only case where OpenID Connect clients don&=
#39;t benefit from PKCE is if they are also confidential clients. Public cl=
ient OIDC clients still need to do PKCE even if they check
 the nonce.




=C2=A0




OpenID Connect servers working with confidentia=
l clients still benefit from PKCE because they can then enforce the authori=
zation code injection protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.<=
/u>




=C2=A0




I really don't think it's worth the amo=
unt of explanation this will take in the future to write an exception into =
OAuth 2.1 or the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.




=C2=A0




Aaron




=C2=A0






=C2=A0


=C2=A0




On Wed, May 6, 2020 at 10:48 AM Dick Hardt <=
dick.hardt@gmail.=
com> wrote:








Hello!



=C2=A0




We would like to have PKCE be a MUST in OAuth 2=
.1 code flows. This is best practice for OAuth 2.0. It is not common in Ope=
nID Connect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.




=C2=A0




The advantages or requiring PKCE are:=





=C2=A0




- a simpler programming model across all OAuth =
applications and profiles as they all use PKCE




=C2=A0




- reduced attack surface when using=C2=A0 S256 =
as a fingerprint of the verifier is sent through the browser instead of the=
 clear text value




=C2=A0




- enforcement by AS not client - makes it easie=
r to handle for client developers and AS can ensure the check is conducted<=
u>




=C2=A0




What are disadvantages besides the potential im=
pact to OpenID Connect deployments? How significant is that impact?<=
u>




=C2=A0




Dick, Aaron, and Torsten




=C2=A0








=E1=90=A7







=C2=A0<=
/u>


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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


=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


3D""=E1=90=A7

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

This sounds like a great use =
of the client credentials grant. The password grant is being removed from O=
Auth 2.0 by the Security Best Current Practice. Can you clarify what=C2=A0y=
ou've found useful about the password grant that the client credentials=
 grant doesn't solve?=C2=A0

Aaron Parecki


On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <beenapurushothaman@gmail.com&g=
t; wrote:
Hi,

We have a product
with client server architecture where our server manages thousands of devic=
es.
Each device has a client-piece that talks to the server over SOAP/REST. The
client currently uses a HTTP Basic Authentication (unique id and a secret
string) for all the calls. The secret string is created when the device enr=
olls
to the server. It is available at the server as well as stored securely on =
the
device. For the rest calls it is the device that is getting authenticated.<=
/p>


=C2=A0



=C2=A0Sending th=
e credentials every time is less
than ideal and we want to move to some tokenized device authentication. We
evaluated OpendID Connect based on the general recommendation of SSO soluti=
on,
but the issue is we do not have any user interaction and hence there is no
Grant flow that is fitting. Hence we evaluated OAuth grant type of which we
found Password Grant and Client Credentials Grant is matching our requireme=
nt.



=C2=A0



=C2=A0In order t=
o use Client Credentials in our use
case, we need to do dynamic registration for the thousands of devices manag=
ed
by the server, if IoT comes into picture the number is going to be even hig=
her,
which is highly cumbersome to manage.=C2=A0
Also, as per=C2=A0 RFC7591 on dynamic
client registration, using access token for registering client is optional
too.=C2=A0 Even though the Password grant is
highly discouraged by the spec, we found it to be highly matching with our
requirements.



=C2=A0



=
But as
per the Oauth 2.1 proposal, password grant is going to be removed. Can
you suggest the way forward for us? I
believe we are not a one-off case.

Thank You,<=
/span>
Beena

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000f9b2e605a54beff6--


From nobody Sun May 10 12:02:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1124B3A0B22 for ; Sun, 10 May 2020 12:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xofCXfoUdIda for ; Sun, 10 May 2020 12:02:07 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650108.outbound.protection.outlook.com [40.107.65.108]) (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 6AD493A0CB0 for ; Sun, 10 May 2020 12:01:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=At8OXWqgN3UWY3iDkPkYjTtK06opuGXNboNXtpuwLPZ2YWZWS5BZ1sSkW/IsmpEQYA07BD/ZqWM2MF/eCet95YoOyqmbhcCbUKqTjrCXt4MkqhRlDbKBZ/1t3XxkWJ2AGTgsZjH+2JGJHl8A3k+p2qEyRrwn4B/1pnFY9uKXTizBEJMpxTu7SSHNObsMOG/T7ZUbIuGFYvFe0YjFXMj0CsiwXQYWYgAK/0T707Vw2le594egNG8rUsUWvUHXDN9RX3hJ1JsL+bFvs0TvKs6B8nZPCHJwJklaQIm/w092ZeYav5rMNr5JaV/fhcgSoaOiRwS1XQQD7IuD4FsoUPfRUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yVyEnrVPNtNFc3pfgIurulOCEa5DBuvLNn0uJA/rdJ4=; b=dbA62W6UswoyWbb/NtN4cYNNdQX/fwLWjxjkU56dG+sqzSud2WIyF0wlfPPiJVTpupyA5Ln83lmXF9Z1o/DucSzizzk68+aT36hrBJ+d9a1ZOk6L/jrS+e8M7XxQh6/2iJ3nsCsfGW6IwUudnaKQGb938LqKRie4RwX5T6uuiPwmPTLgK6vUys6HAFMnAClBhznwAJtRgBodXYbnCZhv4XYFj9JZnxBTVha5gbRMi2eerFhNLfgLSzWJu5ksby0zjgkeuxe4KnJ4Xnvdz1iYc1xKIDKewmfj9tCAF4ZJ+XqmjoVjdXxIhStI40fmwmcfotl9pmqO+hk/BxNrItQG6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yVyEnrVPNtNFc3pfgIurulOCEa5DBuvLNn0uJA/rdJ4=; b=b4WY1lyb8L+68QguFWjkUwpi70Cit1MifFRCc54ddj5DYw9H4MCyHtQmZhHgQEB4SxOuWW5+LgRcpaWzNaNkgXnIed6x621+QhxBD6pqGlvM5hy66ec6sCrLNNT7hfj0nVrQdwiOuMyhRQXEF/KTx6cTx48AM1hw1SKgWqDugTY=
Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0387.namprd00.prod.outlook.com (2603:10b6:207:1f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3028.0; Sun, 10 May 2020 19:01:33 +0000
Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073%7]) with mapi id 15.20.3031.000; Sun, 10 May 2020 19:01:33 +0000
From: Mike Jones 
To: Torsten Lodderstedt 
CC: Daniel Fett , "oauth@ietf.org" 
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
Thread-Index: AdYlWXAnmjsqG17TS+ukF4wvi0+THQBWm+qAABIfH0A=
Date: Sun, 10 May 2020 19:01:32 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1583518f-c910-4446-8304-00003a0c1a5e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-10T18:53:59Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 26617a77-3561-4e05-3d76-08d7f5148e76
x-ms-traffictypediagnostic: BL0PR00MB0387:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 039975700A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VTsy4a7vMGA22dhsUmLMwSlIqpQC9b3J4b1PLecSvRegm48j6r7+R5jvTjYH0uc1Lj5ZmokLV525jOIHydgSgoeteuGqMjlnLrmMc/KJaAmaJiFDt8pT8ieJicPvNy/70xsT1k55d+y33DH04+8YBFY7WRfxkNxo/3j1Y/X9XXoEe1T4BgKX0Dc1EgziEAbf9MBzXAPv02ZksRm/eICpA3+dU05txzIafZ24AJfmX7IF91fxuQjXiGanb/LtQxqHj/SFYIa2guVr6VK71dfboUWUiDocE9+Lc6+es610VBY05wL6hnnl6s1yGiis+GH/j17OAtP3osh+mh5MWZJNOtgnYdA4sjX7U0qMUHbaLTZbrmqTxKqMRFQSFHeR1Fr6VU44JTsB9czZ/NpjdzSMOYe5vDgGaot68l9m8etD9hYXLMmHP5lUyU6iPcgkLDIvaIOeecVEfyhvfu0bzQFZvOjhYPRdpUMJrVjUIsYN7KKWooh/e8MJtrMRyQwIMnK+2yuOd6hCmrMYL14IKRp85A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(33430700001)(54906003)(66476007)(66556008)(64756008)(7696005)(82950400001)(82960400001)(316002)(76116006)(86362001)(52536014)(966005)(478600001)(166002)(66574014)(33656002)(66946007)(33440700001)(66446008)(8936002)(26005)(186003)(5660300002)(53546011)(6506007)(10290500003)(76236002)(2906002)(4326008)(8990500004)(8676002)(9686003)(55016002)(71200400001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: DxuG7lxRS2yVdWXrSvt4VPUB3kjdwpqZn5FXH7eJ/Y2r2Y052eaeW4T1iLhFb42uPNrNZJ58ahQ05JE9GAyIKyXrBWP5dXZZZAfhELLR+95byFNuKC1YpaOd2dkoHOh8znaXdSOG/Qn/DNU/0Tp9zMWwrB84bDbuaSSM2EAr8JG7dfLOzMOtCFSz5TcwRCltqLcjezuPMPNvDhX8rEWYBuiKqnyNUddMTzrwwaCWIjHmX9/bOHJL7bte39fEbPfJmj4tqzAGLe+TmbzPTWbhj+NjXG6GP1bMFVK33VCUAdGXkyS1ZcSBUvy4zMrLOKg2lopBwMTnuKf7vil8/ZiocyigCX9uvVV4kjVwfalU7i3iAwAajeq4HTi3voU1ng9uZCGLJTiCwUQapgiDZRdcbPwjLPXktuTsTu6N4/e3h3AqEgkUGh2th7O95PfoKnk5vLhplpv2w2NzS26q5cGYtCZ4iFbWiyxrJVD2GpO+k0Q=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06881F9246571B60A6E4992EF5A00MN2PR00MB0688namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 26617a77-3561-4e05-3d76-08d7f5148e76
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 19:01:32.7111 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MI59WZVr+6z7PWqLy7XjfYgSFXQCb1ssNpl4BvEQE3dDJNDSTrqk6dHSvQRa4oEUVJI1s2PZfZbzylknTMkUnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0387
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re:  OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 19:02:09 -0000

--_000_MN2PR00MB06881F9246571B60A6E4992EF5A00MN2PR00MB0688namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSB3aXRoIGFjdGl2ZWx5IG1haW50YWluaW5nIGFuZCBpbXByb3ZpbmcgdGhlIE9BdXRo
IDIuMCBzcGVjcyBieSBhZGRpbmcgZW5oYW5jZW1lbnRzIHRoYXQgYXJlIHZvbHVudGFyeSB0byB1
c2UuICBJ4oCZdmUgd29ya2VkIG9uIG1hbnkgc3VjaCBpbXByb3ZlbWVudHMsIGluY2x1ZGluZyBE
eW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24sIEF1dGhvcml6YXRpb24gTWV0YWRhdGEsIHRoZSBE
ZXZpY2UgRmxvdywgVG9rZW4gRXhjaGFuZ2UsIERQb1AsIGFuZCBzdXBwb3J0IFBBUiBhbmQgUkFS
LCBldGMuICBUaGUgaXNzdWUgdGhhdOKAmXMgdGhlIHN1YmplY3QgaXMgdGhlIGN1cnJlbnQgZGlz
Y3Vzc2lvbiBpcyB3aGV0aGVyIHRvIG1ha2UgdXNlIG9mIGFub3RoZXIgZW5oYW5jZW1lbnQsIFBL
Q0UsIG1hbmRhdG9yeSBpbiBjYXNlcyB3aGVyZSBpdOKAmXMgYWN0dWFsbHkgbm90IG5lZWRlZCwg
cmF0aGVyIHRoYW4gbWFraW5nIGl0cyB1c2Ugdm9sdW50YXJ5IGxpa2UgdGhlIG90aGVyIGVuaGFu
Y2VtZW50cywgd2hpY2ggSSBjZXJ0YWlubHkgc3VwcG9ydC4NCg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogVG9y
c3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9y
Zz4NClNlbnQ6IFN1bmRheSwgTWF5IDEwLCAyMDIwIDM6MTUgQU0NClRvOiBNaWtlIEpvbmVzIDxN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpDYzogRGFuaWVsIEZldHQgPGZldHRAZGFuaWVs
ZmV0dC5kZT47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbT0FVVEgt
V0ddIE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KSGkgTWlrZSwNCg0KTWlrZSBKb25lcyA8
TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWlj
cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHNjaHJpZWIgYW0gRnIuIDguIE1haSAyMDIwIHVt
IDE4OjU1Og0KT0F1dGggMi4xIHdhcyBzdXBwb3NlZCB0byBub3QgaW50cm9kdWNlIGJyZWFraW5n
IGNoYW5nZXMuDQpJIGNhbm5vdCByZW1lbWJlciB0aGUgV0cgbWV0IHRoYXQgZGVjaXNpb24uIENh
biB5b3UgcGxlYXNlIHJlZmVyIHRvIHRoZSByZXNwZWN0aXZlIHRocmVhZD8NCg0KUmVxdWlyaW5n
IGV4YWN0IHJlZGlyZWN0IFVSSSBtYXRjaGluZyBpcyBhbHJlYWR5IGEgYnJlYWtpbmcgY2hhbmdl
LiBEbyB5b3Ugb3Bwb3NlIGFnYWluc3QgdGhpcyBhcyB3ZWxsPw0KDQoNCklmIHlvdSB3YW50IHRv
IGRvIHRoYXQsIHBsZWFzZSBkbyBpdCBpbiBUeEF1dGggaW5zdGVhZC4NCg0KSW50ZXJlc3Rpbmcg
c3RhdGVtZW50LiBEb2VzIGl0IG1lYW4geW91IHdhbnQgdG8gY29uc2VydmUgT0F1dGggMi4wIGFu
ZCBmb3JjZSBhbnkgZW5oYW5jZW1lbnRzL2ltcHJvdmVtZW50cyB0byBnbyBpbnRvIFRYQXV0aD8g
VGhpcyB3b3VsZCBjYXVzZSBodWdlIG1pZ3JhdGlvbiBlZmZvcnRzIGZvciBleGlzdGluZyBkZXBs
b3ltZW50cyB3YW50aW5nIHRvIGJlbmVmaXQgZnJvbSB0aG9zZSBlbmhhbmNlbWVudHMuDQoNCkkg
dGhpbmsgZXhpc3RpbmcgZGVwbG95bWVudHMgYXJlIGJldHRlciBzZXJ2ZWQgYnkgYWN0aXZlbHkg
bWFpbnRhaW5pbmcgYW5kIGV2b2x2aW5nIHRoZSAyLnggbGluZS4gRm9yIGV4YW1wbGUsIFBBUiBh
bmQgUkFSIGFyZSBhdHRlbXB0cyB0byBpbXByb3ZlIE9BdXRoIDIueCBhbmQgbWFrZSBpdCB1c2Fi
bGUgZm9yIG5ldyB1c2UgY2FzZXMuIFRoYXTigJlzIGJldHRlciBwcm90ZWN0aW9uIG9mIGV4aXN0
aW5nIGludmVzdG1lbnRzIHRoYW4gc2VuZGluZyB0aGVtIG9mIHRvIFRYQXV0aC4NCktpbmQgcmVn
YXJkcywNClRvcnN0ZW4uDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRGFu
aWVsIEZldHQNClNlbnQ6IFRodXJzZGF5LCBNYXkgNywgMjAyMCAxMTo1MCBQTQ0KVG86IG9hdXRo
QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd
IE9BdXRoIDIuMSAtIHJlcXVpcmUgUEtDRT8NCg0KKzEgdG8gYWxsIHdoYXQgQWFyb24gc2FpZC4g
VGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dCENCg0KV2UgbmVlZCB0byBhZGRyZXNzIHRoaXMg
aW4gdGhlIHNlY3VyaXR5IEJDUCBhbmQgdGhpcyB3aWxsIGJlIGEgbm9ybWF0aXZlIGNoYW5nZSB0
aGF0IGFmZmVjdHMgT3BlbklEIENvbm5lY3QgQ29yZSAoanVzdCBhcyBvdXIgY3VycmVudCByZWNv
bW1lbmRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2Ygbm9uY2UpLg0KDQpXZSB3b3VsZCB0aGVuIGhhdmU6
DQoNCi0gdXNlIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgdXNlIE9JREMgd2l0aCBhIG5vbmNlLCB0aGVu
IHlvdSBkb24ndCBuZWVkIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgYXJlIGEgcHVibGljIGNsaWVudCwg
dGhlbiB5b3Ugc3RpbGwgbmVlZCBQS0NFLg0KLSB1c2Ugc3RhdGUsIGV4Y2VwdCBpZiB5b3UgdXNl
IFBLQ0UsIHRoZW4geW91IGRvbid0IG5lZWQgc3RhdGUuDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHZl
cnkgZ29vZCByZWFzb25zIHRvIHNpbXBsaWZ5IHRoaXMgZG93biB0bw0KDQotIHVzZSBQS0NFDQot
IHlvdSBtYXkgb3IgbWF5IG5vdCB1c2Ugc3RhdGUNCg0KRmlyc3QgYW5kIGZvcmVtb3N0LCBub3Qg
bWFueSBwZW9wbGUgd2lsbCB1bmRlcnN0YW5kIHdoeSB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUg
QkNQL09BdXRoIDIuMSBtYW5kYXRlIFBLQ0UgYW5kIHNvbWUgd2hlcmUgdGhleSBkb24ndC4gSG93
ZXZlciwgdW5kZXJzdGFuZGluZyB3aHkgeW91IGhhdmUgdG8gZG8gc29tZXRoaW5nIGlzIGtleSB0
byBjb21wbGlhbmNlLiBUaGUgc2hvcnQgdmVyc2lvbiAiUEtDRSBwcm90ZWN0cyB0aGUgY29kZTsg
dGhlcmUgaXMgYSBzcGVjaWZpYyBjYXNlIHdoZXJlIGl0IGlzIG5vdCBuZWVkZWQsIGJ1dCBpdHMg
YmV0dGVyIHRvIHVzZSBpdCBhbGwgdGhlIHRpbWUiIGlzIGVhc3kgdG8gdW5kZXJzdGFuZC4gV2Ug
d2lsbCBub3Qgc2VlIG1hbnkgaW1wbGVtZW50YXRpb25zIGZvbGxvd2luZyB0aGUgbG9uZyB2ZXJz
aW9uIGFib3ZlIGNvcnJlY3RseS4NCg0KU2Vjb25kLCB3ZSBkcmFtYXRpY2FsbHkgcmVkdWNlIHRl
Y2huaWNhbCBjb21wbGV4aXR5IGJ5IHJlZHVjaW5nIGNhc2VzIHRoYXQgbmVlZCB0byBiZSBoYW5k
bGVkLiBXZSByZWR1Y2UgY29ycmVjdG5lc3MgYW5kIGNvbXBsaWFuY2UgdGVzdGluZyBjb21wbGV4
aXR5IGluIHRoZSBzYW1lIHdheS4gV2UgcmVkdWNlIHRoZSBjb3N0IG9mIHNlY3VyaXR5IGFuYWx5
c2lzLCB3aGljaCBzY2FsZXMgcmVhbGx5IGJhZGx5IHRvIG1vcmUgY2FzZXMuDQoNCkFuZCBmaW5h
bGx5LCB1c2luZyBub25jZSB0byBwcm90ZWN0IGFnYWluc3QgY29kZSBpbmplY3Rpb24gaXMgbGVz
cyByb2J1c3QgdGhhbiBQS0NFLiBBUyBoYXZlIGEgYmV0dGVyIHRyYWNrIHJlY29yZCB0aGFuIGNs
aWVudHMgd2hlbiBpdCBjb21lcyB0byBjb3JyZWN0bHkgaW1wbGVtZW50aW5nIHNlY3VyaXR5IG1l
Y2hhbmlzbXMuDQoNClllcywgdGhpcyB3aWxsIG1ha2UgYSBudW1iZXIgb2YgaW1wbGVtZW50YXRp
b25zIG5vbi1zcGVjLWNvbXBsaWFudCwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBh
IGh1Z2UgcHJvYmxlbS4gU29mdHdhcmUgbmVlZHMgdG8gYWRhcHQgYWxsIHRoZSB0aW1lIGFuZCBh
IHNvZnR3YXJlIHRoYXQgaGFzIG5vdCBiZWVuIGNoYW5nZWQgaW4gYSB3aGlsZSBpcyBwcm9iYWJs
eSBub3Qgb25lIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhbnl3YXkuIFdlIGFyZSBzZXR0aW5nIGEg
bmV3IGdvYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byBtZWV0IGFuZCBldmVudHVhbGx5LCBtYWlu
dGFpbmVkIGltcGxlbWVudGF0aW9ucyB3aWxsIGdldCB0aGVyZS4NCg0KLURhbmllbA0KDQoNCkFt
IDA4LjA1LjIwIHVtIDAxOjM4IHNjaHJpZWIgQWFyb24gUGFyZWNraToNCkJhY2tpbmcgdXAgYSBz
dGVwIG9yIHR3bywgdGhlcmUncyBhbm90aGVyIHBvaW50IGhlcmUgdGhhdCBJIHRoaW5rIGhhcyBi
ZWVuIG1pc3NlZCBpbiB0aGVzZSBkaXNjdXNzaW9ucy4NCg0KUEtDRSBzb2x2ZXMgdHdvIHByb2Js
ZW1zOiBzdG9sZW4gYXV0aG9yaXphdGlvbiBjb2RlcyBmb3IgcHVibGljIGNsaWVudHMsIGFuZCBh
dXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGZvciBhbGwgY2xpZW50cy4gV2UndmUgb25seSBi
ZWVuIHRhbGtpbmcgYWJvdXQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBvbiB0aGUgbGlz
dCBzbyBmYXIuIFRoZSBxdW90ZWQgc2VjdGlvbiBvZiB0aGUgc2VjdXJpdHkgQkNQICg0LjUuMykg
d2hpY2ggc2F5cyBjbGllbnRzIGNhbiBkbyBQS0NFIG9yIHVzZSB0aGUgbm9uY2UsIGlzIG9ubHkg
dGFsa2luZyBhYm91dCBwcmV2ZW50aW5nIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24uDQoN
ClRoZSBub25jZSBwYXJhbWV0ZXIgc29sdmVzIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24g
aWYgdGhlIGNsaWVudCByZXF1ZXN0cyBhbiBJRCB0b2tlbi4gUHVibGljIGNsaWVudHMgdXNpbmcg
dGhlIG5vbmNlIHBhcmFtZXRlciBhcmUgc3RpbGwgc3VzY2VwdGlibGUgdG8gc3RvbGVuIGF1dGhv
cml6YXRpb24gY29kZXMgc28gdGhleSBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgYXMgd2VsbC4NCg0K
VGhlIG9ubHkgY2FzZSB3aGVyZSBPcGVuSUQgQ29ubmVjdCBjbGllbnRzIGRvbid0IGJlbmVmaXQg
ZnJvbSBQS0NFIGlzIGlmIHRoZXkgYXJlIGFsc28gY29uZmlkZW50aWFsIGNsaWVudHMuIFB1Ymxp
YyBjbGllbnQgT0lEQyBjbGllbnRzIHN0aWxsIG5lZWQgdG8gZG8gUEtDRSBldmVuIGlmIHRoZXkg
Y2hlY2sgdGhlIG5vbmNlLg0KDQpPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIHdvcmtpbmcgd2l0aCBj
b25maWRlbnRpYWwgY2xpZW50cyBzdGlsbCBiZW5lZml0IGZyb20gUEtDRSBiZWNhdXNlIHRoZXkg
Y2FuIHRoZW4gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBwcm90ZWN0
aW9uIHNlcnZlci1zaWRlIHJhdGhlciB0aGFuIGNyb3NzIHRoZWlyIGZpbmdlcnMgdGhhdCBjbGll
bnRzIGltcGxlbWVudGVkIHRoZSBub25jZSBjaGVjayBwcm9wZXJseS4NCg0KSSByZWFsbHkgZG9u
J3QgdGhpbmsgaXQncyB3b3J0aCB0aGUgYW1vdW50IG9mIGV4cGxhbmF0aW9uIHRoaXMgd2lsbCB0
YWtlIGluIHRoZSBmdXR1cmUgdG8gd3JpdGUgYW4gZXhjZXB0aW9uIGludG8gT0F1dGggMi4xIG9y
IHRoZSBTZWN1cml0eSBCQ1AgZm9yIG9ubHkgc29tZSB0eXBlcyBvZiBPcGVuSUQgQ29ubmVjdCBj
bGllbnRzIHdoZW4gYWxsIGNsaWVudHMgd291bGQgYmVuZWZpdCBmcm9tIFBLQ0UgYW55d2F5Lg0K
DQpBYXJvbg0KDQoNCg0KT24gV2VkLCBNYXkgNiwgMjAyMCBhdCAxMDo0OCBBTSBEaWNrIEhhcmR0
IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90
ZToNCkhlbGxvIQ0KDQpXZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1
dGggMi4xIGNvZGUgZmxvd3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJ
dCBpcyBub3QgY29tbW9uIGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNv
bHZlcyBzb21lIG9mIHRoZSBpc3N1ZXMgdGhhdCBQS0NFIHByb3RlY3RzIGFnYWluc3QuIFdlIHRo
aW5rIHRoYXQgbW9zdCBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBzdXBwb3J0
IE9BdXRoIDIuMCwgYW5kIGhlbmNlIGhhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcg
YmVzdCBwcmFjdGljZXMuDQoNClRoZSBhZHZhbnRhZ2VzIG9yIHJlcXVpcmluZyBQS0NFIGFyZToN
Cg0KLSBhIHNpbXBsZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNh
dGlvbnMgYW5kIHByb2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NFDQoNCi0gcmVkdWNlZCBhdHRh
Y2sgc3VyZmFjZSB3aGVuIHVzaW5nICBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlm
aWVyIGlzIHNlbnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0
IHZhbHVlDQoNCi0gZW5mb3JjZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2ll
ciB0byBoYW5kbGUgZm9yIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBj
aGVjayBpcyBjb25kdWN0ZWQNCg0KV2hhdCBhcmUgZGlzYWR2YW50YWdlcyBiZXNpZGVzIHRoZSBw
b3RlbnRpYWwgaW1wYWN0IHRvIE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRzPyBIb3cgc2lnbmlm
aWNhbnQgaXMgdGhhdCBpbXBhY3Q/DQoNCkRpY2ssIEFhcm9uLCBhbmQgVG9yc3Rlbg0KDQrhkKcN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpP
QXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp
bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_MN2PR00MB06881F9246571B60A6E4992EF5A00MN2PR00MB0688namp_
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
bWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz
O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K
PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91
dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBhZ3Jl
ZSB3aXRoIGFjdGl2ZWx5IG1haW50YWluaW5nIGFuZCBpbXByb3ZpbmcgdGhlIE9BdXRoIDIuMCBz
cGVjcyBieSBhZGRpbmcgZW5oYW5jZW1lbnRzIHRoYXQgYXJlIHZvbHVudGFyeSB0byB1c2UuJm5i
c3A7IEnigJl2ZSB3b3JrZWQgb24gbWFueSBzdWNoIGltcHJvdmVtZW50cywgaW5jbHVkaW5nIER5
bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiwgQXV0aG9yaXphdGlvbg0KIE1ldGFkYXRhLCB0aGUg
RGV2aWNlIEZsb3csIFRva2VuIEV4Y2hhbmdlLCBEUG9QLCBhbmQgc3VwcG9ydCBQQVIgYW5kIFJB
UiwgZXRjLiZuYnNwOyBUaGUgaXNzdWUgdGhhdOKAmXMgdGhlIHN1YmplY3QgaXMgdGhlIGN1cnJl
bnQgZGlzY3Vzc2lvbiBpcyB3aGV0aGVyIHRvIG1ha2UgdXNlIG9mIGFub3RoZXIgZW5oYW5jZW1l
bnQsIFBLQ0UsIG1hbmRhdG9yeSBpbiBjYXNlcyB3aGVyZSBpdOKAmXMgYWN0dWFsbHkgbm90IG5l
ZWRlZCwgcmF0aGVyIHRoYW4gbWFraW5nDQogaXRzIHVzZSB2b2x1bnRhcnkgbGlrZSB0aGUgb3Ro
ZXIgZW5oYW5jZW1lbnRzLCB3aGljaCBJIGNlcnRhaW5seSBzdXBwb3J0LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv
bTo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRA
ZG1hcmMuaWV0Zi5vcmcmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXkgMTAsIDIw
MjAgMzoxNSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0Bt
aWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRGFuaWVsIEZldHQgJmx0O2ZldHRAZGFu
aWVsZmV0dC5kZSZndDs7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRF
Uk5BTF0gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWlrZSw8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pa2UgSm9u
ZXMgJmx0O01pY2hhZWwuSm9uZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZyI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgc2Nocmll
YiBhbSBGci4gOC4gTWFpIDIwMjAgdW0gMTg6NTU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp
Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPk9BdXRoIDIuMSB3YXMgc3VwcG9zZWQgdG8gbm90IGludHJvZHVj
ZSBicmVha2luZyBjaGFuZ2VzLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW5u
b3QgcmVtZW1iZXIgdGhlIFdHIG1ldCB0aGF0IGRlY2lzaW9uLiBDYW4geW91IHBsZWFzZSByZWZl
ciB0byB0aGUgcmVzcGVjdGl2ZSB0aHJlYWQ/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlcXVpcmluZyBleGFjdCByZWRpcmVjdCBV
UkkgbWF0Y2hpbmcgaXMgYWxyZWFkeSBhIGJyZWFraW5nIGNoYW5nZS4gRG8geW91IG9wcG9zZSBh
Z2FpbnN0IHRoaXMgYXMgd2VsbD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp
biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPklmIHlvdSB3YW50IHRvIGRvIHRoYXQsIHBsZWFzZSBkbyBpdCBpbiBUeEF1
dGggaW5zdGVhZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZXJlc3Rpbmcgc3RhdGVt
ZW50LiBEb2VzIGl0IG1lYW4geW91IHdhbnQgdG8gY29uc2VydmUgT0F1dGggMi4wIGFuZCBmb3Jj
ZSBhbnkgZW5oYW5jZW1lbnRzL2ltcHJvdmVtZW50cyB0byBnbyBpbnRvIFRYQXV0aD8gVGhpcyB3
b3VsZCBjYXVzZSBodWdlIG1pZ3JhdGlvbiBlZmZvcnRzIGZvciBleGlzdGluZyBkZXBsb3ltZW50
cyB3YW50aW5nIHRvIGJlbmVmaXQgZnJvbSB0aG9zZSBlbmhhbmNlbWVudHMuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgZXhpc3Rp
bmcgZGVwbG95bWVudHMgYXJlIGJldHRlciBzZXJ2ZWQgYnkgYWN0aXZlbHkgbWFpbnRhaW5pbmcg
YW5kIGV2b2x2aW5nIHRoZSAyLnggbGluZS4gRm9yIGV4YW1wbGUsIFBBUiBhbmQgUkFSIGFyZSBh
dHRlbXB0cyB0byBpbXByb3ZlIE9BdXRoIDIueCBhbmQgbWFrZSBpdCB1c2FibGUgZm9yIG5ldyB1
c2UgY2FzZXMuIFRoYXTigJlzIGJldHRlciBwcm90ZWN0aW9uIG9mIGV4aXN0aW5nIGludmVzdG1l
bnRzDQogdGhhbiBzZW5kaW5nIHRoZW0gb2YgdG8gVFhBdXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9yc3Rlbi48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9i
PiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBP
ZiA8L2I+RGFuaWVsIEZldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSA3LCAyMDIw
IDExOjUwIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UmU6IFtPQVVUSC1XR10gT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mIzQzOzEgdG8gYWxsIHdoYXQgQWFy
b24gc2FpZC4gVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dCE8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIG5lZWQgdG8gYWRkcmVz
cyB0aGlzIGluIHRoZSBzZWN1cml0eSBCQ1AgYW5kIHRoaXMgd2lsbCBiZSBhIG5vcm1hdGl2ZSBj
aGFuZ2UgdGhhdCBhZmZlY3RzIE9wZW5JRCBDb25uZWN0IENvcmUgKGp1c3QgYXMgb3VyIGN1cnJl
bnQgcmVjb21tZW5kYXRpb24gb24gdGhlIHVzYWdlIG9mIG5vbmNlKS48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIHdvdWxkIHRoZW4g
aGF2ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPi0gdXNlIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgdXNlIE9JREMgd2l0aCBhIG5vbmNlLCB0
aGVuIHlvdSBkb24ndCBuZWVkIFBLQ0UsIGV4Y2VwdCBpZiB5b3UgYXJlIGEgcHVibGljIGNsaWVu
dCwgdGhlbiB5b3Ugc3RpbGwgbmVlZCBQS0NFLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHVzZSBzdGF0ZSwgZXhjZXB0IGlmIHlvdSB1c2Ug
UEtDRSwgdGhlbiB5b3UgZG9uJ3QgbmVlZCBzdGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhlcmUgYXJlIHZlcnkg
Z29vZCByZWFzb25zIHRvIHNpbXBsaWZ5IHRoaXMgZG93biB0bw0KPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHVzZSBQS0NFPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0geW91IG1h
eSBvciBtYXkgbm90IHVzZSBzdGF0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rmlyc3QgYW5kIGZvcmVtb3N0LCBub3QgbWFueSBwZW9w
bGUgd2lsbCB1bmRlcnN0YW5kIHdoeSB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUgQkNQL09BdXRo
IDIuMSBtYW5kYXRlIFBLQ0UgYW5kIHNvbWUgd2hlcmUgdGhleSBkb24ndC4gSG93ZXZlciwgdW5k
ZXJzdGFuZGluZw0KPGk+d2h5PC9pPiB5b3UgaGF2ZSB0byBkbyBzb21ldGhpbmcgaXMga2V5IHRv
IGNvbXBsaWFuY2UuIFRoZSBzaG9ydCB2ZXJzaW9uICZxdW90O1BLQ0UgcHJvdGVjdHMgdGhlIGNv
ZGU7IHRoZXJlIGlzIGEgc3BlY2lmaWMgY2FzZSB3aGVyZSBpdCBpcyBub3QgbmVlZGVkLCBidXQg
aXRzIGJldHRlciB0byB1c2UgaXQgYWxsIHRoZSB0aW1lJnF1b3Q7IGlzIGVhc3kgdG8gdW5kZXJz
dGFuZC4gV2Ugd2lsbCBub3Qgc2VlIG1hbnkgaW1wbGVtZW50YXRpb25zIGZvbGxvd2luZw0KIHRo
ZSBsb25nIHZlcnNpb24gYWJvdmUgY29ycmVjdGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2Vjb25kLCB3ZSBkcmFtYXRpY2FsbHkg
cmVkdWNlIHRlY2huaWNhbCBjb21wbGV4aXR5IGJ5IHJlZHVjaW5nIGNhc2VzIHRoYXQgbmVlZCB0
byBiZSBoYW5kbGVkLiBXZSByZWR1Y2UgY29ycmVjdG5lc3MgYW5kIGNvbXBsaWFuY2UgdGVzdGlu
ZyBjb21wbGV4aXR5IGluIHRoZSBzYW1lIHdheS4gV2UgcmVkdWNlDQogdGhlIGNvc3Qgb2Ygc2Vj
dXJpdHkgYW5hbHlzaXMsIHdoaWNoIHNjYWxlcyByZWFsbHkgYmFkbHkgdG8gbW9yZSBjYXNlcy48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PkFuZCBmaW5hbGx5LCB1c2luZyBub25jZSB0byBwcm90ZWN0IGFnYWluc3QgY29kZSBpbmplY3Rp
b24gaXMgbGVzcyByb2J1c3QgdGhhbiBQS0NFLiBBUyBoYXZlIGEgYmV0dGVyIHRyYWNrIHJlY29y
ZCB0aGFuIGNsaWVudHMgd2hlbiBpdCBjb21lcyB0byBjb3JyZWN0bHkgaW1wbGVtZW50aW5nIHNl
Y3VyaXR5DQogbWVjaGFuaXNtcy4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIHRoaXMgd2lsbCBtYWtlIGEgbnVtYmVyIG9mIGlt
cGxlbWVudGF0aW9ucyBub24tc3BlYy1jb21wbGlhbnQsIGJ1dCBJIGRvIG5vdCB0aGluayB0aGF0
IHRoaXMgaXMgYSBodWdlIHByb2JsZW0uIFNvZnR3YXJlIG5lZWRzIHRvIGFkYXB0IGFsbCB0aGUg
dGltZSBhbmQgYSBzb2Z0d2FyZSB0aGF0IGhhcw0KIG5vdCBiZWVuIGNoYW5nZWQgaW4gYSB3aGls
ZSBpcyBwcm9iYWJseSBub3Qgb25lIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhbnl3YXkuIFdlIGFy
ZSBzZXR0aW5nIGEgbmV3IGdvYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byBtZWV0IGFuZCBldmVu
dHVhbGx5LCBtYWludGFpbmVkIGltcGxlbWVudGF0aW9ucyB3aWxsIGdldCB0aGVyZS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1EYW5p
ZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5BbSAwOC4wNS4yMCB1bSAwMTozOCBzY2hyaWViIEFhcm9uIFBhcmVja2k6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUncyBhbm90aGVyIHBvaW50IGhlcmUgdGhh
dCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVzZSBkaXNjdXNzaW9ucy4NCjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBLQ0Ugc29sdmVzIHR3
byBwcm9ibGVtczogc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgZm9yIHB1YmxpYyBjbGllbnRz
LCBhbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBmb3IgYWxsIGNsaWVudHMuIFdlJ3Zl
IG9ubHkgYmVlbiB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24NCiBv
biB0aGUgbGlzdCBzbyBmYXIuIFRoZSBxdW90ZWQgc2VjdGlvbiBvZiB0aGUgc2VjdXJpdHkgQkNQ
ICg0LjUuMykgd2hpY2ggc2F5cyBjbGllbnRzIGNhbiBkbyBQS0NFIG9yIHVzZSB0aGUgbm9uY2Us
IGlzIG9ubHkgdGFsa2luZyBhYm91dCBwcmV2ZW50aW5nIGF1dGhvcml6YXRpb24gY29kZSBpbmpl
Y3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5UaGUgbm9uY2UgcGFyYW1ldGVyIHNvbHZlcyBhdXRob3JpemF0aW9uIGNvZGUgaW5q
ZWN0aW9uIGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gSUQgdG9rZW4uIFB1YmxpYyBjbGllbnRz
IHVzaW5nIHRoZSBub25jZSBwYXJhbWV0ZXIgYXJlIHN0aWxsIHN1c2NlcHRpYmxlIHRvIHN0b2xl
biBhdXRob3JpemF0aW9uDQogY29kZXMgc28gdGhleSBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgYXMg
d2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPlRoZSBvbmx5IGNhc2Ugd2hlcmUgT3BlbklEIENvbm5lY3QgY2xpZW50cyBkb24ndCBi
ZW5lZml0IGZyb20gUEtDRSBpcyBpZiB0aGV5IGFyZSBhbHNvIGNvbmZpZGVudGlhbCBjbGllbnRz
LiBQdWJsaWMgY2xpZW50IE9JREMgY2xpZW50cyBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgZXZlbiBp
ZiB0aGV5IGNoZWNrDQogdGhlIG5vbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3BlbklEIENvbm5lY3Qgc2VydmVycyB3b3JraW5n
IHdpdGggY29uZmlkZW50aWFsIGNsaWVudHMgc3RpbGwgYmVuZWZpdCBmcm9tIFBLQ0UgYmVjYXVz
ZSB0aGV5IGNhbiB0aGVuIGVuZm9yY2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24g
cHJvdGVjdGlvbiBzZXJ2ZXItc2lkZSZuYnNwO3JhdGhlciZuYnNwO3RoYW4NCiBjcm9zcyB0aGVp
ciBmaW5nZXJzIHRoYXQgY2xpZW50cyBpbXBsZW1lbnRlZCB0aGUgbm9uY2UgY2hlY2sgcHJvcGVy
bHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5JIHJlYWxseSBkb24ndCB0aGluayBpdCdzIHdvcnRoIHRoZSBhbW91bnQgb2YgZXhwbGFu
YXRpb24gdGhpcyB3aWxsIHRha2UgaW4gdGhlIGZ1dHVyZSB0byB3cml0ZSBhbiBleGNlcHRpb24g
aW50byBPQXV0aCAyLjEgb3IgdGhlIFNlY3VyaXR5IEJDUCBmb3Igb25seSBzb21lIHR5cGVzIG9m
IE9wZW5JRCBDb25uZWN0DQogY2xpZW50cyB3aGVuIGFsbCBjbGllbnRzIHdvdWxkIGJlbmVmaXQg
ZnJvbSBQS0NFIGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkFhcm9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgTWF5IDYsIDIwMjAgYXQg
MTA6NDggQU0gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVs
bG8hDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5X
ZSB3b3VsZCBsaWtlIHRvIGhhdmUgUEtDRSBiZSBhIE1VU1QgaW4gT0F1dGggMi4xIGNvZGUgZmxv
d3MuIFRoaXMgaXMgYmVzdCBwcmFjdGljZSBmb3IgT0F1dGggMi4wLiBJdCBpcyBub3QgY29tbW9u
IGluIE9wZW5JRCBDb25uZWN0IHNlcnZlcnMgYXMgdGhlIG5vbmNlIHNvbHZlcyBzb21lIG9mIHRo
ZSBpc3N1ZXMNCiB0aGF0IFBLQ0UgcHJvdGVjdHMgYWdhaW5zdC4gV2UgdGhpbmsgdGhhdCBtb3N0
IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQgT0F1dGggMi4wLCBh
bmQgaGVuY2UmbmJzcDtoYXZlIHN1cHBvcnQgZm9yIFBLQ0UgaWYgZm9sbG93aW5nIGJlc3QgcHJh
Y3RpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+VGhlIGFkdmFudGFnZXMgb3IgcmVxdWlyaW5nIFBLQ0UgYXJlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBhIHNpbXBs
ZXIgcHJvZ3JhbW1pbmcgbW9kZWwgYWNyb3NzIGFsbCBPQXV0aCBhcHBsaWNhdGlvbnMgYW5kIHBy
b2ZpbGVzIGFzIHRoZXkgYWxsIHVzZSBQS0NFPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHJlZHVjZWQgYXR0YWNrIHN1cmZhY2Ugd2hl
biB1c2luZyZuYnNwOyBTMjU2IGFzIGEgZmluZ2VycHJpbnQgb2YgdGhlIHZlcmlmaWVyIGlzIHNl
bnQgdGhyb3VnaCB0aGUgYnJvd3NlciBpbnN0ZWFkIG9mIHRoZSBjbGVhciB0ZXh0IHZhbHVlPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t
IGVuZm9yY2VtZW50IGJ5IEFTIG5vdCBjbGllbnQgLSBtYWtlcyBpdCBlYXNpZXIgdG8gaGFuZGxl
IGZvciBjbGllbnQgZGV2ZWxvcGVycyBhbmQgQVMgY2FuIGVuc3VyZSB0aGUgY2hlY2sgaXMgY29u
ZHVjdGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5XaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIGJlc2lkZXMgdGhlIHBvdGVudGlhbCBpbXBh
Y3QgdG8gT3BlbklEIENvbm5lY3QgZGVwbG95bWVudHM/IEhvdyBzaWduaWZpY2FudCBpcyB0aGF0
IGltcGFjdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkRpY2ssIEFhcm9uLCBhbmQgVG9yc3RlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpbWcg
Ym9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBzdHlsZT0id2lkdGg6LjAxMDRpbjtoZWln
aHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBw
c3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlw
ZT16ZXJvY29udGVudCZhbXA7Z3VpZD00NTI0MzhiYS1kNDI5LTQ2NTYtYWNlOS1iMjg0NzQ0YmMx
NzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBs
aXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxw
cmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_MN2PR00MB06881F9246571B60A6E4992EF5A00MN2PR00MB0688namp_--


From nobody Sun May 10 12:02:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB23A0B26 for ; Sun, 10 May 2020 12:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqspc1C5unMv for ; Sun, 10 May 2020 12:02:29 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650090.outbound.protection.outlook.com [40.107.65.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660E83A0B52 for ; Sun, 10 May 2020 12:02:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dao2HWcNurosAFhGbmxoG4GYN5fkGT+8cebsdqQrw6Zd0TWmdt6SwCUNJRZivueyoMnjj5SQoHnK8gbBzx7N8e56XtqSfcB24Wq/3XAO5JBvrNGd2IDykS8nhkWeEERKiwHnUKmTHIrdGlMlW5/0WAK83GP3qqkxAev4DcI1k8U4DhFPjFQscdfgptOUGLywrM21lIQ0DGH1s6DOFs3dSs0LH3JyQhiBw4Mzvezb8vN/GeabkRCM56RCvurbdDjYjZx1DsEsZvW2+3kKclhDWlrGNtVrYP/Qk4TKWZQYKwR23sJvv340+9Y4TD5rSpVQheuLH4AOVibgtSOMMtyyJg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7y7MTPRJ6fD+19peGpc/qBkqFdSwMpXMsMATrLaAQeU=; b=S1uciaSTjvKMDGd/79Z48J7JDvLD6Xn1Dz43lpaK8LL+H3t7NkzB2xmkejR/BK2RIF/5a+hSGcvLzFoZ4xvCrH4K5SyHRZxOPYPmUSeGtfRK49Bu3vu26uL0qSAjL1/WZQojvlRmIouBBCYe2oGDVlnG78L0cxU9UR2VQFPNFfrMIcnoyTvOS+mpB+CSVKPf00uUJuTr6apXPLLqioChY4HIqXmQgSrk/gT2/nB0M4WTCOHTruT8e6RRU7ypDDQZthAFdsI5Wh1OxukkticNU3+XGJaptnqKRR2CL3e5w5bHOa6a9eBojb+cbcV3cqDis0YKQuzieW9JKuOaO6A/+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7y7MTPRJ6fD+19peGpc/qBkqFdSwMpXMsMATrLaAQeU=; b=Ki7SGAeeJXGkwzfq6ViSjDLzg+mNguoXfvkT1FDbJqJWAsiPWwM+1/4641SX+111ZX1u4+9bokOPfNRfx37afnDqQ4rwfOXMdgQaNEjBOyqjUxV3VXzKzfXR+YveFg87DMg7ty6tvwgZzvWddhPkd116JJ/hr8IzzmILOtlo7DA=
Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0387.namprd00.prod.outlook.com (2603:10b6:207:1f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3028.0; Sun, 10 May 2020 19:02:26 +0000
Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8ef:3352:9393:c073%7]) with mapi id 15.20.3031.000; Sun, 10 May 2020 19:02:26 +0000
From: Mike Jones 
To: Torsten Lodderstedt 
CC: Aaron Parecki , Dick Hardt , OAuth WG 
Thread-Topic: OAuth 2.1 - require PKCE?
Thread-Index: AdYm/YVC+Jlk78yPRaultu1s74SIrw==
Date: Sun, 10 May 2020 19:02:26 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=867b6992-783e-4192-bb87-0000d2391bad; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-10T18:53:19Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 76d11500-3815-4adc-06b3-08d7f514ae10
x-ms-traffictypediagnostic: BL0PR00MB0387:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 039975700A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TISSo2op4ZV0GAg8Q3n+tmk+Zhr1GL68pH+A2bmHz3jHjIcTSfr8sh/RGq2r4zWXa7FdvPcbtJ91Y7QsF8gRp1GzBnapVGJr3MhSCFQMYBWTXXBQ91KfGUjVYXCNfwtW2RUOZM8wYJqIOYLSQVxXySmFv5H9V6mjMuXruUbHT6JGAMRaQomx+mS79K0OL1fuAwf/pmtRj6b/amTTYMa1QKSiZjnj83l42qPXm1Om+jL0sBK0jDEqK33K8Kb4ayZiTeC0Zx2bhtIHN0aDqRoQJoUBZozBUAO2irq9TEoJ7kQUlg0VZHbGkyChkrB5TIWmUL08Gf8AkJNr+zhvg7hUB9Rbr+gh0q5rS6ck5RrBd8DXyfQJO33SHgQx/eshHOpWiY4pLbZOAbeKsZOG2w98HlMauTyl+w3ju5HUIXIG+YOCbJDWql4ShhCzoNCUyzn8
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(33430700001)(54906003)(66476007)(66556008)(64756008)(7696005)(82950400001)(82960400001)(316002)(76116006)(6916009)(86362001)(52536014)(478600001)(66574014)(33656002)(66946007)(33440700001)(66446008)(8936002)(26005)(186003)(5660300002)(53546011)(6506007)(10290500003)(76236002)(2906002)(4326008)(8990500004)(8676002)(9686003)(55016002)(71200400001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: rK/b4hN9O/15hlBs0oSWhL4pjdCOu/YkK2gkUtQ6OczLUbcfvvxZB3RyFDGHFrwTSlJ5tCw0pTzPLJ4tjGgY6LybnkKHDd3i4CLL1ZwFDSfbEePh9DgGOXZb5z/MlfoPy0Jqrh2tYR+9v8iHq9qZ+aQLbTmAi4I5SgIz2MFYbFRSomprrM0pozGMBKOwXL5xC84lCNWCLtHh/FCv89qj6G3xNK21qHtreaE6YHlRYsM0ZdoQwl2zAAEHn/I4GYfG77eA9RliyK/pCIL09NEFUYOkk5VEJ4NgvbGWiKnwfr3K/NLnDwcqhSOvtR40T5ruPqkh9qBqYzno7FXyKaAM4MFglp6MQJQRHm3JvZ47D6bSPdhTZ58szSDXXFJ05C61n26by29uDyMkHtj1rU3ODWhm/b6zKnGg6P34pNAQYPw4oErR+WZv7nHzJXrIR/C/22LDvzRrKyrXz0PfSoX6PE6bGtlY6YmDw0rp80SortI=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688E35CB78EA69D1A3F0A65F5A00MN2PR00MB0688namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 76d11500-3815-4adc-06b3-08d7f514ae10
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 19:02:26.3844 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /DLwW8JadwCkPAgAVrr6Dv/MssHgOBTuCr/1fHRGW9doFECLbGu2kt0fic96AdLK1/4Jj9Cgmu13abs6gTLJyg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0387
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 19:02:38 -0000

--_000_MN2PR00MB0688E35CB78EA69D1A3F0A65F5A00MN2PR00MB0688namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBEaWQgSSBnb3QgaXQgcmlnaHQgdGhhdCBub25jZSBkb2VzIG5vdCBwcm90ZWN0IHB1YmxpYyBj
bGllbnRzIGZyb20gY29kZSB0aGVmdC9yZXBsYXk/DQoNCkkgYmVsaWV2ZSB0aGF0IHRoZSBPcGVu
SUQgQ29ubmVjdCBDb2RlIEhhc2ggKOKAnGNfaGFzaOKAnSkgY2xhaW0gcHJvdGVjdHMgYWdhaW5z
dCB0aGlzLiAgSeKAmWQgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIEpvaG4gQnJhZGxleeKAmXMg
dGFrZSBvbiB0aGlzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3Jz
dGVuQGxvZGRlcnN0ZWR0Lm5ldD4NClNlbnQ6IFN1bmRheSwgTWF5IDEwLCAyMDIwIDM6MTcgQU0N
ClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpDYzogQWFyb24g
UGFyZWNraSA8YWFyb25AcGFyZWNraS5jb20+OyBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls
LmNvbT47IE9BdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBPQXV0aCAyLjEg
LSByZXF1aXJlIFBLQ0U/DQoNCk1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gc2NocmllYiBhbSBTYS4gOS4g
TWFpIDIwMjAgdW0gMjA6NDY6DQpUaGVyZeKAmXMgYSBodWdlIGVjb3N5c3RlbSBvZiBzdWNjZXNz
ZnVsLCBzZWN1cmUgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cyB0aGF0
IHdlIGhhdmUgdGhlIHJlc3BvbnNpYmlsaXR5IHRvIGJlIHN0ZXdhcmRzIG9mLiAgVGhpcyB3b3Jr
aW5nIGdyb3VwIHNob3VsZCBiZSBwcm91ZCBvZiB3aGF0IGl04oCZcyBhY2NvbXBsaXNoZWQuICBQ
YXJ0IG9mIGdvb2Qgc3Rld2FyZHNoaXAgaXMgbm90IHVubmVjZXNzYXJpbHkgYmlmdXJjYXRpbmcg
dGhlIGVjb3N5c3RlbSBpbnRvIG5vbi1pbnRlcm9wZXJhYmxlIHNlZ21lbnRzLiAgT0F1dGggMi4x
IHNob3VsZCBmYWNpbGl0YXRlIHRoZSBhbHJlYWR5IHNlY3VyZSBPQXV0aCAyLjAgZGVwbG95bWVu
dHMgcmVtYWluaW5nIHBhcnQgb2YgdGhlIGludGVyb3BlcmFibGUgT0F1dGggMi4xIHNldCBvZiBk
ZXBsb3ltZW50cyDigJMgbm90IGludGVudGlvbmFsbHkgZG9pbmcgdGhlIG9wcG9zaXRlLg0KDQpJ
ZiBpdCBhaW7igJl0IGJyb2tlLCBkb27igJl0IGZpeCBpdCENCkRpZCBJIGdvdCBpdCByaWdodCB0
aGF0IG5vbmNlIGRvZXMgbm90IHByb3RlY3QgcHVibGljIGNsaWVudHMgZnJvbSBjb2RlIHRoZWZ0
L3JlcGxheT8gSSB3b3VsZCBjb25zaWRlciB0aGlzIGEgc2VjdXJpdHkgaXNzdWUuDQoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl
DQoNCkZyb206IEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBw
YXJlY2tpLmNvbT4+DQpTZW50OiBGcmlkYXksIE1heSA4LCAyMDIwIDg6MzQgUE0NClRvOiBPQXV0
aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCkNjOiBEaWNrIEhh
cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pjsg
VG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0
ZW5AbG9kZGVyc3RlZHQubmV0Pj47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NClN1YmplY3Q6IFJlOiBP
QXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/DQoNCkFhcm9uLCBJIGJlbGlldmUgeW914oCZcmUgdHJ5
aW5nIHRvIG9wdGltaXplIHRoZSB3cm9uZyB0aGluZy4gIFlvdeKAmXJlIGNvbmNlcm5lZCBhYm91
dCDigJx0aGUgYW1vdW50IG9mIGV4cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtl4oCdLiAgVGhhdOKA
mXMgb3B0aW1pemluZyBmb3Igc3BlYyBzaW1wbGljaXR5IOKAkyBhIGdvYWwgdGhhdCBJIGRvIHVu
ZGVyc3RhbmQuICBIb3dldmVyLCBieSB3cml0aW5nIHRoZXNlIGZldyBzZW50ZW5jZXMgb3IgcGFy
YWdyYXBocywgd2XigJlsbCBtYWtlIGl0IGNsZWFyIHRvIGRldmVsb3BlcnMgdGhhdCBodW5kcmVk
cyBvciB0aG91c2FuZHMgb2YgZGVwbG95ZWQgT3BlbklEIENvbm5lY3QgUlBzIHdvbuKAmXQgaGF2
ZSB0byBjaGFuZ2UgdGhlaXIgZGVwbG95bWVudHMuICBUaGF04oCZcyBvcHRpbWl6aW5nIGZvciBp
bnRlcm9wZXJhYmlsaXR5IGFuZCBtaW5pbWl6aW5nIHRoZSBidXJkZW4gb24gZGV2ZWxvcGVycywg
d2hpY2ggYXJlIGZhciBtb3JlIGltcG9ydGFudC4NCg0KSSBhcHByZWNpYXRlIHRoZSBjb25jZXJu
IGFib3V0IG9wdGltaXppbmcgZm9yIHNwZWMgc2ltcGxpY2l0eS4gSSBhbHNvIGFncmVlIHRoYXQg
c3BlYyBzaW1wbGljaXR5IHNob3VsZCBub3QgbmVjZXNzYXJpbHkgYmUgdGhlIGRyaXZpbmcgZ29h
bC4NCg0KSG93ZXZlciwgd2hhdCB5b3UndmUgZGVzY3JpYmVkIGlzIHRoZSBvcHBvc2l0ZSBvZiBp
bnRlcm9wZXJhYmlsaXR5IGFuZCBtaW5pbWl6aW5nIHRoZSBidXJkZW4gb24gZGV2ZWxvcGVycy4g
UmVxdWlyaW5nIFBLQ0UgaW4gT0F1dGggMi4xLCB3aXRob3V0IGFueSBleGNlcHRpb25zLCB3aWxs
IG9wdGltaXplIGZvciBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gT0F1dGggMi4xIGNsaWVudHMg
YW5kIHNlcnZlcnMuIFdpdGhvdXQgdGhlIHJlcXVpcmVtZW50IG9mIFBLQ0UsIHRoZXJlIHdpbGwg
YWx3YXlzIGJlIHRoZSBxdWVzdGlvbiBvZiAiYnV0IGRvZXMgdGhpcyBPQXV0aCAyLjEgY2xpZW50
IHdvcmsgd2l0aCB0aGlzIE9BdXRoIDIuMSBzZXJ2ZXIgb3Igbm90PyIsIHdoaWNoIHdpbGwgb25s
eSBiZSBhYmxlIHRvIGJlIGFuc3dlcmVkIGJ5IGludmVzdGlnYXRpbmcgdGhlIGRvY3MgdG8gbG9v
ayBmb3IgUEtDRSBzdXBwb3J0LCBvciBieSBjaGVja2luZyB0aGUgQVMgbWV0YWRhdGEgZG9jdW1l
bnQgaWYgaXQgcHVibGlzaGVzIG9uZSAod2hpY2ggaXQgaXMgbm90IHJlcXVpcmVkIHRvIGRvKS4N
Cg0KT3B0aW1pemluZyBmb3IgaW50ZXJvcGVyYWJpbGl0eSBhbmQgbWluaW1pemluZyB0aGUgYnVy
ZGVuIG9uIGRldmVsb3BlcnMgaXMgYWJzb2x1dGVseSBhIGdvb2QgZ29hbCwgYW5kIHJlcXVpcmlu
ZyBQS0NFIGlzIGEgZ3JlYXQgd2F5IHRvIGFjY29tcGxpc2ggdGhhdC4gT0F1dGggMi4wIGFuZCBP
cGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb24ndCBzdXBwb3J0IFBLQ0Ugd2ls
bCBjb250aW51ZSB0byB3b3JrIGFzIHRoZXkgY3VycmVudGx5IGRvLCB0aGV5IGp1c3Qgd29uJ3Qg
YmUgYWJsZSB0byBjYWxsIHRoZW1zZWx2ZXMgT0F1dGggMi4xIGNvbXBsaWFudCwganVzdCBhcyBp
cyB0aGUgY2FzZSBhcyBpZiB0aGV5IGRvbid0IGZvbGxvdyB0aGUgb3RoZXIgcmVjb21tZW5kYXRp
b25zIHRoYXQgYXJlIGluIE9BdXRoIDIuMSBhbmQgdGhlIFNlY3VyaXR5IEJDUC4NCg0KQWFyb24N
Cg0KDQpPbiBUaHUsIE1heSA3LCAyMDIwIGF0IDY6NDIgUE0gTWlrZSBKb25lcyA8TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3
cm90ZToNCkFhcm9uLCBJIGJlbGlldmUgeW914oCZcmUgdHJ5aW5nIHRvIG9wdGltaXplIHRoZSB3
cm9uZyB0aGluZy4gIFlvdeKAmXJlIGNvbmNlcm5lZCBhYm91dCDigJx0aGUgYW1vdW50IG9mIGV4
cGxhbmF0aW9uIHRoaXMgd2lsbCB0YWtl4oCdLiAgVGhhdOKAmXMgb3B0aW1pemluZyBmb3Igc3Bl
YyBzaW1wbGljaXR5IOKAkyBhIGdvYWwgdGhhdCBJIGRvIHVuZGVyc3RhbmQuICBIb3dldmVyLCBi
eSB3cml0aW5nIHRoZXNlIGZldyBzZW50ZW5jZXMgb3IgcGFyYWdyYXBocywgd2XigJlsbCBtYWtl
IGl0IGNsZWFyIHRvIGRldmVsb3BlcnMgdGhhdCBodW5kcmVkcyBvciB0aG91c2FuZHMgb2YgZGVw
bG95ZWQgT3BlbklEIENvbm5lY3QgUlBzIHdvbuKAmXQgaGF2ZSB0byBjaGFuZ2UgdGhlaXIgZGVw
bG95bWVudHMuICBUaGF04oCZcyBvcHRpbWl6aW5nIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBt
aW5pbWl6aW5nIHRoZSBidXJkZW4gb24gZGV2ZWxvcGVycywgd2hpY2ggYXJlIGZhciBtb3JlIGlt
cG9ydGFudC4NCg0KQXMgQnJpYW4gQ2FtcGJlbGwgd3JvdGUsIOKAnFRoZXkgYXJlIG5vdCBlcXVp
dmFsZW50IGFuZCBoYXZlIHZlcnkgZGlmZmVyZW50IHJhbWlmaWNhdGlvbnMgb24gaW50ZXJvcGVy
YWJpbGl0eeKAnS4NCg0KRXZlbiBpZiB5b3XigJlyZSBvcHRpbWl6aW5nIGZvciB3cml0aW5nLCB0
YWtpbmcgYSBtaW5pbWFsbHkgaW52YXNpdmUgcHJvdG9jb2wgY2hhbmdlIGFwcHJvYWNoIHdpbGwg
b3B0aW1pemUgdGhhdCwgb3ZlcmFsbC4gIElmIHdlIHByb2NlZWQgYXMgeW914oCZcmUgc3VnZ2Vz
dGluZywgYSBodWdlIGFtb3VudCBvZiB3cml0aW5nIHdpbGwgb2NjdXIgb24gU3RhY2tPdmVyZmxv
dywgTWVkaXVtLCBTbGFzaERvdCwgYmxvZ3MsIGFuZCBvdGhlciBkZXZlbG9wZXIgZm9ydW1zLCB3
aGVyZSBjb25mdXNlZCBkZXZlbG9wZXJzIHdpbGwgYXNrIOKAnFdoeSBkbyBJIGhhdmUgdG8gY2hh
bmdlIG15IGRlcGxveWVkIGNvZGU/4oCdIHdpdGggdGhlIGFuc3dlcnMgYmVpbmcg4oCcRGVzcGl0
ZSB3aGF0IHRoZSAyLjEgc3BlYyBzYXlzLCB0aGVyZeKAmXMgbm8gbmVlZCB0byBjaGFuZ2UgeW91
ciBkZXBsb3llZCBjb2RlLuKAnQ0KDQpJ4oCZZCBnbGFkbHkgd3JpdGUgYSBmZXcgc2VudGVuY2Vz
IGluIG91ciBuZXcgc3BlY3Mgbm93IHRvIHByZXZlbnQgb25nb2luZyBjb25mdXNpb24gYW5kIGlu
dGVyb3AgcHJvYmxlbXMgdGhhdCB3b3VsZCBvdGhlcndpc2UgcmVzdWx0LiAgTGV0IG1lIGtub3cg
d2hlbiB5b3XigJlyZSByZWFkeSB0byBpbmNvcnBvcmF0ZSB0aGVtIGludG8gdGhlIHNwZWMgdGV4
dC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIC0tIE1pa2UNCg0KRnJvbTogQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb208bWFp
bHRvOmFhcm9uQHBhcmVja2kuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBNYXkgNywgMjAyMCA0OjM5
IFBNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFy
ZHRAZ21haWwuY29tPj4NCkNjOiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo
QGlldGYub3JnPj47IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0
PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpT
dWJqZWN0OiBSZTogT0F1dGggMi4xIC0gcmVxdWlyZSBQS0NFPw0KDQpCYWNraW5nIHVwIGEgc3Rl
cCBvciB0d28sIHRoZXJlJ3MgYW5vdGhlciBwb2ludCBoZXJlIHRoYXQgSSB0aGluayBoYXMgYmVl
biBtaXNzZWQgaW4gdGhlc2UgZGlzY3Vzc2lvbnMuDQoNClBLQ0Ugc29sdmVzIHR3byBwcm9ibGVt
czogc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMgZm9yIHB1YmxpYyBjbGllbnRzLCBhbmQgYXV0
aG9yaXphdGlvbiBjb2RlIGluamVjdGlvbiBmb3IgYWxsIGNsaWVudHMuIFdlJ3ZlIG9ubHkgYmVl
biB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gb24gdGhlIGxpc3Qg
c28gZmFyLiBUaGUgcXVvdGVkIHNlY3Rpb24gb2YgdGhlIHNlY3VyaXR5IEJDUCAoNC41LjMpIHdo
aWNoIHNheXMgY2xpZW50cyBjYW4gZG8gUEtDRSBvciB1c2UgdGhlIG5vbmNlLCBpcyBvbmx5IHRh
bGtpbmcgYWJvdXQgcHJldmVudGluZyBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uLg0KDQpU
aGUgbm9uY2UgcGFyYW1ldGVyIHNvbHZlcyBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIGlm
IHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gSUQgdG9rZW4uIFB1YmxpYyBjbGllbnRzIHVzaW5nIHRo
ZSBub25jZSBwYXJhbWV0ZXIgYXJlIHN0aWxsIHN1c2NlcHRpYmxlIHRvIHN0b2xlbiBhdXRob3Jp
emF0aW9uIGNvZGVzIHNvIHRoZXkgc3RpbGwgbmVlZCB0byBkbyBQS0NFIGFzIHdlbGwuDQoNClRo
ZSBvbmx5IGNhc2Ugd2hlcmUgT3BlbklEIENvbm5lY3QgY2xpZW50cyBkb24ndCBiZW5lZml0IGZy
b20gUEtDRSBpcyBpZiB0aGV5IGFyZSBhbHNvIGNvbmZpZGVudGlhbCBjbGllbnRzLiBQdWJsaWMg
Y2xpZW50IE9JREMgY2xpZW50cyBzdGlsbCBuZWVkIHRvIGRvIFBLQ0UgZXZlbiBpZiB0aGV5IGNo
ZWNrIHRoZSBub25jZS4NCg0KT3BlbklEIENvbm5lY3Qgc2VydmVycyB3b3JraW5nIHdpdGggY29u
ZmlkZW50aWFsIGNsaWVudHMgc3RpbGwgYmVuZWZpdCBmcm9tIFBLQ0UgYmVjYXVzZSB0aGV5IGNh
biB0aGVuIGVuZm9yY2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gcHJvdGVjdGlv
biBzZXJ2ZXItc2lkZSByYXRoZXIgdGhhbiBjcm9zcyB0aGVpciBmaW5nZXJzIHRoYXQgY2xpZW50
cyBpbXBsZW1lbnRlZCB0aGUgbm9uY2UgY2hlY2sgcHJvcGVybHkuDQoNCkkgcmVhbGx5IGRvbid0
IHRoaW5rIGl0J3Mgd29ydGggdGhlIGFtb3VudCBvZiBleHBsYW5hdGlvbiB0aGlzIHdpbGwgdGFr
ZSBpbiB0aGUgZnV0dXJlIHRvIHdyaXRlIGFuIGV4Y2VwdGlvbiBpbnRvIE9BdXRoIDIuMSBvciB0
aGUgU2VjdXJpdHkgQkNQIGZvciBvbmx5IHNvbWUgdHlwZXMgb2YgT3BlbklEIENvbm5lY3QgY2xp
ZW50cyB3aGVuIGFsbCBjbGllbnRzIHdvdWxkIGJlbmVmaXQgZnJvbSBQS0NFIGFueXdheS4NCg0K
QWFyb24NCg0KDQoNCk9uIFdlZCwgTWF5IDYsIDIwMjAgYXQgMTA6NDggQU0gRGljayBIYXJkdCA8
ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6
DQpIZWxsbyENCg0KV2Ugd291bGQgbGlrZSB0byBoYXZlIFBLQ0UgYmUgYSBNVVNUIGluIE9BdXRo
IDIuMSBjb2RlIGZsb3dzLiBUaGlzIGlzIGJlc3QgcHJhY3RpY2UgZm9yIE9BdXRoIDIuMC4gSXQg
aXMgbm90IGNvbW1vbiBpbiBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXJzIGFzIHRoZSBub25jZSBzb2x2
ZXMgc29tZSBvZiB0aGUgaXNzdWVzIHRoYXQgUEtDRSBwcm90ZWN0cyBhZ2FpbnN0LiBXZSB0aGlu
ayB0aGF0IG1vc3QgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBP
QXV0aCAyLjAsIGFuZCBoZW5jZSBoYXZlIHN1cHBvcnQgZm9yIFBLQ0UgaWYgZm9sbG93aW5nIGJl
c3QgcHJhY3RpY2VzLg0KDQpUaGUgYWR2YW50YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6DQoN
Ci0gYSBzaW1wbGVyIHByb2dyYW1taW5nIG1vZGVsIGFjcm9zcyBhbGwgT0F1dGggYXBwbGljYXRp
b25zIGFuZCBwcm9maWxlcyBhcyB0aGV5IGFsbCB1c2UgUEtDRQ0KDQotIHJlZHVjZWQgYXR0YWNr
IHN1cmZhY2Ugd2hlbiB1c2luZyAgUzI1NiBhcyBhIGZpbmdlcnByaW50IG9mIHRoZSB2ZXJpZmll
ciBpcyBzZW50IHRocm91Z2ggdGhlIGJyb3dzZXIgaW5zdGVhZCBvZiB0aGUgY2xlYXIgdGV4dCB2
YWx1ZQ0KDQotIGVuZm9yY2VtZW50IGJ5IEFTIG5vdCBjbGllbnQgLSBtYWtlcyBpdCBlYXNpZXIg
dG8gaGFuZGxlIGZvciBjbGllbnQgZGV2ZWxvcGVycyBhbmQgQVMgY2FuIGVuc3VyZSB0aGUgY2hl
Y2sgaXMgY29uZHVjdGVkDQoNCldoYXQgYXJlIGRpc2FkdmFudGFnZXMgYmVzaWRlcyB0aGUgcG90
ZW50aWFsIGltcGFjdCB0byBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cz8gSG93IHNpZ25pZmlj
YW50IGlzIHRoYXQgaW1wYWN0Pw0KDQpEaWNrLCBBYXJvbiwgYW5kIFRvcnN0ZW4NCg0K4ZCnDQo=

--_000_MN2PR00MB0688E35CB78EA69D1A3F0A65F5A00MN2PR00MB0688namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+
PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y
OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N
Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t
LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy
IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkdhZHVnaTsNCglwYW5vc2Ut
MToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O
b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx
LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh
cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZndDsgPC9z
cGFuPkRpZCBJIGdvdCBpdCByaWdodCB0aGF0IG5vbmNlIGRvZXMgbm90IHByb3RlY3QgcHVibGlj
IGNsaWVudHMgZnJvbSBjb2RlIHRoZWZ0L3JlcGxheT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSBiZWxpZXZlIHRoYXQgdGhlIE9wZW5JRCBDb25uZWN0IENvZGUgSGFzaCAo4oCcY19oYXNo4oCd
KSBjbGFpbSBwcm90ZWN0cyBhZ2FpbnN0IHRoaXMuJm5ic3A7IEnigJlkIGJlIGludGVyZXN0ZWQg
aW4gaGVhcmluZyBKb2huIEJyYWRsZXnigJlzIHRha2Ugb24gdGhpcy48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8
c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPkZyb206PC9iPiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVuQGxvZGRl
cnN0ZWR0Lm5ldCZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDEwLCAyMDIwIDM6
MTcgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEFhcm9uIFBhcmVja2kgJmx0O2Fhcm9uQHBhcmVj
a2kuY29tJmd0OzsgRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7OyBPQXV0
aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBPQXV0
aCAyLjEgLSByZXF1aXJlIFBLQ0U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsg
c2NocmllYiBhbSBTYS4gOS4gTWFpIDIwMjAgdW0gMjA6NDY6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZXJl4oCZcyBhIGh1Z2UgZWNvc3lzdGVtIG9mIHN1
Y2Nlc3NmdWwsIHNlY3VyZSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IGRlcGxveW1lbnRz
IHRoYXQgd2UgaGF2ZSB0aGUgcmVzcG9uc2liaWxpdHkgdG8gYmUgc3Rld2FyZHMgb2YuJm5ic3A7
IFRoaXMgd29ya2luZw0KIGdyb3VwIHNob3VsZCBiZSBwcm91ZCBvZiB3aGF0IGl04oCZcyBhY2Nv
bXBsaXNoZWQuJm5ic3A7IFBhcnQgb2YgZ29vZCBzdGV3YXJkc2hpcCBpcyBub3QgdW5uZWNlc3Nh
cmlseSBiaWZ1cmNhdGluZyB0aGUgZWNvc3lzdGVtIGludG8gbm9uLWludGVyb3BlcmFibGUgc2Vn
bWVudHMuJm5ic3A7IE9BdXRoIDIuMSBzaG91bGQgZmFjaWxpdGF0ZSB0aGUgYWxyZWFkeSBzZWN1
cmUgT0F1dGggMi4wIGRlcGxveW1lbnRzIHJlbWFpbmluZyBwYXJ0IG9mIHRoZSBpbnRlcm9wZXJh
YmxlDQogT0F1dGggMi4xIHNldCBvZiBkZXBsb3ltZW50cyDigJMgbm90IGludGVudGlvbmFsbHkg
ZG9pbmcgdGhlIG9wcG9zaXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw
NjAiPklmIGl0IGFpbuKAmXQgYnJva2UsIGRvbuKAmXQgZml4IGl0ITwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+RGlkIEkgZ290IGl0IHJpZ2h0IHRoYXQgbm9uY2UgZG9lcyBub3QgcHJvdGVjdCBw
dWJsaWMgY2xpZW50cyBmcm9tIGNvZGUgdGhlZnQvcmVwbGF5PyBJIHdvdWxkIGNvbnNpZGVyIHRo
aXMgYSBzZWN1cml0eSBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6
IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxiPkZyb206PC9iPiBBYXJvbiBQYXJlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFy
b25AcGFyZWNraS5jb20iIHRhcmdldD0iX2JsYW5rIj5hYXJvbkBwYXJlY2tpLmNvbTwvYT4mZ3Q7
DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgOCwgMjAyMCA4OjM0IFBNPGJyPg0KPGI+
VG86PC9iPiBPQXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRGljayBI
YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i
bGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OzsgVG9yc3RlbiBMb2RkZXJzdGVkdCAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFu
ayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OzsgTWlrZSBKb25lcyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBPQXV0aCAyLjEgLSByZXF1aXJlIFBLQ0U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkFhcm9uLCBJIGJlbGlldmUgeW914oCZcmUgdHJ5aW5nIHRvIG9wdGltaXplIHRoZSB3
cm9uZyB0aGluZy4mbmJzcDsgWW914oCZcmUgY29uY2VybmVkIGFib3V0IOKAnHRoZSBhbW91bnQg
b2YgZXhwbGFuYXRpb24gdGhpcyB3aWxsIHRha2XigJ0uJm5ic3A7IFRoYXTigJlzIG9wdGltaXpp
bmcgZm9yIHNwZWMgc2ltcGxpY2l0eSDigJMgYSBnb2FsIHRoYXQNCiBJIGRvIHVuZGVyc3RhbmQu
Jm5ic3A7IEhvd2V2ZXIsIGJ5IHdyaXRpbmcgdGhlc2UgZmV3IHNlbnRlbmNlcyBvciBwYXJhZ3Jh
cGhzLCB3ZeKAmWxsIG1ha2UgaXQgY2xlYXIgdG8gZGV2ZWxvcGVycyB0aGF0IGh1bmRyZWRzIG9y
IHRob3VzYW5kcyBvZiBkZXBsb3llZCBPcGVuSUQgQ29ubmVjdCBSUHMgd29u4oCZdCBoYXZlIHRv
IGNoYW5nZSB0aGVpciBkZXBsb3ltZW50cy4mbmJzcDsgVGhhdOKAmXMgb3B0aW1pemluZyBmb3Ig
aW50ZXJvcGVyYWJpbGl0eSBhbmQgbWluaW1pemluZw0KIHRoZSBidXJkZW4gb24gZGV2ZWxvcGVy
cywgd2hpY2ggYXJlIGZhciBtb3JlIGltcG9ydGFudC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFwcHJlY2lhdGUgdGhl
IGNvbmNlcm4gYWJvdXQgb3B0aW1pemluZyBmb3Igc3BlYyBzaW1wbGljaXR5LiBJIGFsc28gYWdy
ZWUgdGhhdCBzcGVjIHNpbXBsaWNpdHkgc2hvdWxkIG5vdCBuZWNlc3NhcmlseSBiZSB0aGUgZHJp
dmluZyBnb2FsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SG93ZXZlciwgd2hhdCB5b3UndmUgZGVzY3JpYmVkIGlzIHRoZSBvcHBvc2l0
ZSBvZiBpbnRlcm9wZXJhYmlsaXR5IGFuZCBtaW5pbWl6aW5nIHRoZSBidXJkZW4gb24gZGV2ZWxv
cGVycy4gUmVxdWlyaW5nIFBLQ0UgaW4gT0F1dGggMi4xLCB3aXRob3V0IGFueSBleGNlcHRpb25z
LCB3aWxsIG9wdGltaXplIGZvcg0KIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBPQXV0aCAyLjEg
Y2xpZW50cyBhbmQgc2VydmVycy4gV2l0aG91dCB0aGUgcmVxdWlyZW1lbnQgb2YgUEtDRSwgdGhl
cmUgd2lsbCBhbHdheXMgYmUgdGhlIHF1ZXN0aW9uIG9mICZxdW90O2J1dCBkb2VzIHRoaXMgT0F1
dGggMi4xIGNsaWVudCB3b3JrIHdpdGggdGhpcyBPQXV0aCAyLjEgc2VydmVyIG9yIG5vdD8mcXVv
dDssIHdoaWNoIHdpbGwgb25seSBiZSBhYmxlIHRvIGJlIGFuc3dlcmVkIGJ5IGludmVzdGlnYXRp
bmcNCiB0aGUgZG9jcyB0byBsb29rIGZvciBQS0NFIHN1cHBvcnQsIG9yIGJ5IGNoZWNraW5nIHRo
ZSBBUyBtZXRhZGF0YSBkb2N1bWVudCBpZiBpdCBwdWJsaXNoZXMgb25lICh3aGljaCBpdCBpcyBu
b3QgcmVxdWlyZWQgdG8gZG8pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+T3B0aW1pemluZyBmb3IgaW50ZXJvcGVyYWJpbGl0eSBhbmQg
bWluaW1pemluZyB0aGUgYnVyZGVuIG9uIGRldmVsb3BlcnMgaXMgYWJzb2x1dGVseSBhIGdvb2Qg
Z29hbCwgYW5kIHJlcXVpcmluZyBQS0NFIGlzIGEgZ3JlYXQgd2F5IHRvIGFjY29tcGxpc2ggdGhh
dC4gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdA0KIGltcGxlbWVudGF0aW9ucyB0aGF0IGRv
bid0IHN1cHBvcnQgUEtDRSB3aWxsIGNvbnRpbnVlIHRvIHdvcmsgYXMgdGhleSBjdXJyZW50bHkg
ZG8sIHRoZXkganVzdCB3b24ndCBiZSBhYmxlIHRvIGNhbGwgdGhlbXNlbHZlcyBPQXV0aCAyLjEg
Y29tcGxpYW50LCBqdXN0IGFzIGlzIHRoZSBjYXNlIGFzIGlmIHRoZXkgZG9uJ3QgZm9sbG93IHRo
ZSBvdGhlciByZWNvbW1lbmRhdGlvbnMgdGhhdCBhcmUgaW4gT0F1dGggMi4xIGFuZCB0aGUgU2Vj
dXJpdHkNCiBCQ1AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5BYXJvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgTWF5IDcsIDIwMjAgYXQgNjo0
MiBQTSBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv
ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6
MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BYXJvbiwgSSBiZWxpZXZlIHlvdeKA
mXJlIHRyeWluZyB0byBvcHRpbWl6ZSB0aGUgd3JvbmcgdGhpbmcuJm5ic3A7IFlvdeKAmXJlIGNv
bmNlcm5lZCBhYm91dCDigJw8L3NwYW4+dGhlIGFtb3VudCBvZiBleHBsYW5hdGlvbiB0aGlzIHdp
bGwgdGFrZTxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7igJ0uJm5ic3A7DQogVGhhdOKAmXMg
b3B0aW1pemluZyBmb3Igc3BlYyBzaW1wbGljaXR5IOKAkyBhIGdvYWwgdGhhdCBJIGRvIHVuZGVy
c3RhbmQuJm5ic3A7IEhvd2V2ZXIsIGJ5IHdyaXRpbmcgdGhlc2UgZmV3IHNlbnRlbmNlcyBvciBw
YXJhZ3JhcGhzLCB3ZeKAmWxsIG1ha2UgaXQgY2xlYXIgdG8gZGV2ZWxvcGVycyB0aGF0IGh1bmRy
ZWRzIG9yIHRob3VzYW5kcyBvZiBkZXBsb3llZCBPcGVuSUQgQ29ubmVjdCBSUHMgd29u4oCZdCBo
YXZlIHRvIGNoYW5nZSB0aGVpciBkZXBsb3ltZW50cy4mbmJzcDsNCiBUaGF04oCZcyBvcHRpbWl6
aW5nIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBtaW5pbWl6aW5nIHRoZSBidXJkZW4gb24gZGV2
ZWxvcGVycywgd2hpY2ggYXJlIGZhciBtb3JlIGltcG9ydGFudC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BcyBCcmlhbiBDYW1wYmVsbCB3cm90ZSwg4oCcPC9zcGFu
PlRoZXkgYXJlIG5vdCBlcXVpdmFsZW50IGFuZCBoYXZlIHZlcnkgZGlmZmVyZW50IHJhbWlmaWNh
dGlvbnMgb24gaW50ZXJvcGVyYWJpbGl0eTxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7igJ0u
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+RXZlbiBpZiB5b3XigJly
ZSBvcHRpbWl6aW5nIGZvciB3cml0aW5nLCB0YWtpbmcgYSBtaW5pbWFsbHkgaW52YXNpdmUgcHJv
dG9jb2wgY2hhbmdlIGFwcHJvYWNoIHdpbGwgb3B0aW1pemUgdGhhdCwgb3ZlcmFsbC4mbmJzcDsg
SWYgd2UgcHJvY2VlZCBhcyB5b3XigJlyZSBzdWdnZXN0aW5nLA0KIGEgaHVnZSBhbW91bnQgb2Yg
d3JpdGluZyB3aWxsIG9jY3VyIG9uIFN0YWNrT3ZlcmZsb3csIE1lZGl1bSwgU2xhc2hEb3QsIGJs
b2dzLCBhbmQgb3RoZXIgZGV2ZWxvcGVyIGZvcnVtcywgd2hlcmUgY29uZnVzZWQgZGV2ZWxvcGVy
cyB3aWxsIGFzayDigJxXaHkgZG8gSSBoYXZlIHRvIGNoYW5nZSBteSBkZXBsb3llZCBjb2RlP+KA
nSB3aXRoIHRoZSBhbnN3ZXJzIGJlaW5nIOKAnERlc3BpdGUgd2hhdCB0aGUgMi4xIHNwZWMgc2F5
cywgdGhlcmXigJlzIG5vIG5lZWQNCiB0byBjaGFuZ2UgeW91ciBkZXBsb3llZCBjb2RlLuKAnTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPknigJlkIGdsYWRseSB3cml0
ZSBhIGZldyBzZW50ZW5jZXMgaW4gb3VyIG5ldyBzcGVjcyBub3cgdG8gcHJldmVudCBvbmdvaW5n
IGNvbmZ1c2lvbiBhbmQgaW50ZXJvcCBwcm9ibGVtcyB0aGF0IHdvdWxkIG90aGVyd2lzZSByZXN1
bHQuJm5ic3A7IExldCBtZSBrbm93IHdoZW4NCiB5b3XigJlyZSByZWFkeSB0byBpbmNvcnBvcmF0
ZSB0aGVtIGludG8gdGhlIHNwZWMgdGV4dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr
ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IEFh
cm9uIFBhcmVja2kgJmx0OzxhIGhyZWY9Im1haWx0bzphYXJvbkBwYXJlY2tpLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPmFhcm9uQHBhcmVja2kuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBU
aHVyc2RheSwgTWF5IDcsIDIwMjAgNDozOSBQTTxicj4NCjxiPlRvOjwvYj4gRGljayBIYXJkdCAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+
ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0cgJmx0
OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGll
dGYub3JnPC9hPiZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0
b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvcnN0ZW5AbG9kZGVyc3Rl
ZHQubmV0PC9hPiZndDs7IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogT0F1dGggMi4xIC0gcmVxdWly
ZSBQS0NFPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PkJhY2tpbmcgdXAgYSBzdGVwIG9yIHR3bywgdGhlcmUncyBhbm90aGVyIHBvaW50IGhlcmUgdGhh
dCBJIHRoaW5rIGhhcyBiZWVuIG1pc3NlZCBpbiB0aGVzZSBkaXNjdXNzaW9ucy48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QS0NFIHNvbHZlcyB0d28g
cHJvYmxlbXM6IHN0b2xlbiBhdXRob3JpemF0aW9uIGNvZGVzIGZvciBwdWJsaWMgY2xpZW50cywg
YW5kIGF1dGhvcml6YXRpb24gY29kZSBpbmplY3Rpb24gZm9yIGFsbCBjbGllbnRzLiBXZSd2ZSBv
bmx5IGJlZW4gdGFsa2luZyBhYm91dCBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uDQogb24g
dGhlIGxpc3Qgc28gZmFyLiBUaGUgcXVvdGVkIHNlY3Rpb24gb2YgdGhlIHNlY3VyaXR5IEJDUCAo
NC41LjMpIHdoaWNoIHNheXMgY2xpZW50cyBjYW4gZG8gUEtDRSBvciB1c2UgdGhlIG5vbmNlLCBp
cyBvbmx5IHRhbGtpbmcgYWJvdXQgcHJldmVudGluZyBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0
aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+VGhlIG5vbmNlIHBhcmFtZXRlciBzb2x2ZXMgYXV0aG9yaXphdGlvbiBjb2RlIGluamVj
dGlvbiBpZiB0aGUgY2xpZW50IHJlcXVlc3RzIGFuIElEIHRva2VuLiBQdWJsaWMgY2xpZW50cyB1
c2luZyB0aGUgbm9uY2UgcGFyYW1ldGVyIGFyZSBzdGlsbCBzdXNjZXB0aWJsZSB0byBzdG9sZW4g
YXV0aG9yaXphdGlvbg0KIGNvZGVzIHNvIHRoZXkgc3RpbGwgbmVlZCB0byBkbyBQS0NFIGFzIHdl
bGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5UaGUgb25seSBjYXNlIHdoZXJlIE9wZW5JRCBDb25uZWN0IGNsaWVudHMgZG9uJ3QgYmVu
ZWZpdCBmcm9tIFBLQ0UgaXMgaWYgdGhleSBhcmUgYWxzbyBjb25maWRlbnRpYWwgY2xpZW50cy4g
UHVibGljIGNsaWVudCBPSURDIGNsaWVudHMgc3RpbGwgbmVlZCB0byBkbyBQS0NFIGV2ZW4gaWYg
dGhleSBjaGVjaw0KIHRoZSBub25jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9wZW5JRCBDb25uZWN0IHNlcnZlcnMgd29ya2luZyB3
aXRoIGNvbmZpZGVudGlhbCBjbGllbnRzIHN0aWxsIGJlbmVmaXQgZnJvbSBQS0NFIGJlY2F1c2Ug
dGhleSBjYW4gdGhlbiBlbmZvcmNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5qZWN0aW9uIHBy
b3RlY3Rpb24gc2VydmVyLXNpZGUmbmJzcDtyYXRoZXImbmJzcDt0aGFuDQogY3Jvc3MgdGhlaXIg
ZmluZ2VycyB0aGF0IGNsaWVudHMgaW1wbGVtZW50ZWQgdGhlIG5vbmNlIGNoZWNrIHByb3Blcmx5
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+SSByZWFsbHkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0aCB0aGUgYW1vdW50IG9mIGV4cGxhbmF0
aW9uIHRoaXMgd2lsbCB0YWtlIGluIHRoZSBmdXR1cmUgdG8gd3JpdGUgYW4gZXhjZXB0aW9uIGlu
dG8gT0F1dGggMi4xIG9yIHRoZSBTZWN1cml0eSBCQ1AgZm9yIG9ubHkgc29tZSB0eXBlcyBvZiBP
cGVuSUQgQ29ubmVjdA0KIGNsaWVudHMgd2hlbiBhbGwgY2xpZW50cyB3b3VsZCBiZW5lZml0IGZy
b20gUEtDRSBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5BYXJvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIE1heSA2LCAyMDIwIGF0IDEw
OjQ4IEFNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbGxv
ITxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIHdv
dWxkIGxpa2UgdG8gaGF2ZSBQS0NFIGJlIGEgTVVTVCBpbiBPQXV0aCAyLjEgY29kZSBmbG93cy4g
VGhpcyBpcyBiZXN0IHByYWN0aWNlIGZvciBPQXV0aCAyLjAuIEl0IGlzIG5vdCBjb21tb24gaW4g
T3BlbklEIENvbm5lY3Qgc2VydmVycyBhcyB0aGUgbm9uY2Ugc29sdmVzIHNvbWUgb2YgdGhlIGlz
c3Vlcw0KIHRoYXQgUEtDRSBwcm90ZWN0cyBhZ2FpbnN0LiBXZSB0aGluayB0aGF0IG1vc3QgT3Bl
bklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25zIGFsc28gc3VwcG9ydCBPQXV0aCAyLjAsIGFuZCBo
ZW5jZSZuYnNwO2hhdmUgc3VwcG9ydCBmb3IgUEtDRSBpZiBmb2xsb3dpbmcgYmVzdCBwcmFjdGlj
ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5UaGUgYWR2YW50YWdlcyBvciByZXF1aXJpbmcgUEtDRSBhcmU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIGEgc2ltcGxlciBw
cm9ncmFtbWluZyBtb2RlbCBhY3Jvc3MgYWxsIE9BdXRoIGFwcGxpY2F0aW9ucyBhbmQgcHJvZmls
ZXMgYXMgdGhleSBhbGwgdXNlIFBLQ0U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gcmVkdWNlZCBhdHRhY2sgc3VyZmFjZSB3aGVuIHVz
aW5nJm5ic3A7IFMyNTYgYXMgYSBmaW5nZXJwcmludCBvZiB0aGUgdmVyaWZpZXIgaXMgc2VudCB0
aHJvdWdoIHRoZSBicm93c2VyIGluc3RlYWQgb2YgdGhlIGNsZWFyIHRleHQgdmFsdWU8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gZW5m
b3JjZW1lbnQgYnkgQVMgbm90IGNsaWVudCAtIG1ha2VzIGl0IGVhc2llciB0byBoYW5kbGUgZm9y
IGNsaWVudCBkZXZlbG9wZXJzIGFuZCBBUyBjYW4gZW5zdXJlIHRoZSBjaGVjayBpcyBjb25kdWN0
ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPldoYXQgYXJlIGRpc2FkdmFudGFnZXMgYmVzaWRlcyB0aGUgcG90ZW50aWFsIGltcGFjdCB0
byBPcGVuSUQgQ29ubmVjdCBkZXBsb3ltZW50cz8gSG93IHNpZ25pZmljYW50IGlzIHRoYXQgaW1w
YWN0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+RGljaywgQWFyb24sIGFuZCBUb3JzdGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGltZyBib3Jk
ZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hlaWdodDou
MDEwNGluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90
LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXpl
cm9jb250ZW50JmFtcDtndWlkPTQ1MjQzOGJhLWQ0MjktNDY1Ni1hY2U5LWIyODQ3NDRiYzE3MSI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_MN2PR00MB0688E35CB78EA69D1A3F0A65F5A00MN2PR00MB0688namp_--


From nobody Sun May 10 12:39:13 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4490B3A0BBC for ; Sun, 10 May 2020 12:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a55DXvK4XME8 for ; Sun, 10 May 2020 12:38:44 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 D02543A0B86 for ; Sun, 10 May 2020 12:38:43 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id g1so1299827ljk.7 for ; Sun, 10 May 2020 12:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xXBoQq5UZnLGjDyJO7sBAQ3BTp8JfjrwaI5ZDMgwUro=; b=TksPIucalJIB3F6YvdQVVI/zn7DB8DlUF/2OZR41zDVVCAaNn0EObaQXbUbvQmMQNj fX+9B7YadBJQBVGbnAnU2nyja4UlFv2ux3fCvRT9nq2m4SakBXeQfWIPAi5rXYEm7NAu h7IQfZ4wWcUBxP3A2OpmNGr6iXP/ng47axB1l/W6LtyAnutVq2BzpgZ9+5uVnLdihzrz Kzh3DXecfGbUqtUMEXrdye4ErhTq9z9BAYmkDJ/zWHUCRBThGrIXN1SHoMjuVhDNqu93 Ob8hWttK5EA0KwVBBQmhmV5YOovGQP05MKqZ8ykLDcFhsSfvlg+H0yWQK4MCjIqKWbVM rWqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xXBoQq5UZnLGjDyJO7sBAQ3BTp8JfjrwaI5ZDMgwUro=; b=V7zJgLZNKsHs2Y8HiaIi2mhjoD06ymrDj0So/XbXnPhudWj8Nih6O0hAFiZ58rsK+y zsG1A/7Pf7DXc7BNKzQQ9xUqhrCChzz8+Y4YyaSrCn0cMUXDbF+mRxjrG5N0fowlke/7 sBY5kidsm0LKOlTzw1enPXgH01wGHRYuo05/+Jh+zT3BbbJYEZJzX+91t2e0eE/T7rOT M7ePSablCd1NhLLsMHAdeHoTqzMINmKMQQgz4us9UjbnQez+BWbSMzrSqUeLfteJOsLD VgP5HD3gla2TT+8Tc5CmAuBvR9bP+MOo1lNAjUkssN9clYp7Ha0weX7R/7i9M651JHvZ Xslw==
X-Gm-Message-State: AOAM531rVQ8xwyOrPWhQQoYeplC28vNAUEh/WxX/VEgnz3gNG/Utjfo2 wKSXai2ikkunUHO7Fm5fpiWMOWZwQBH1r8BvpVDu+u+v
X-Google-Smtp-Source: ABdhPJz92tmEzbXsGJHUZ7593ZYdNElkLrgFIhSY7QZbSDbzw/U6CFkbfjmwAAuBvNVHXmCHXt8ykBb4Wbaw2R3yttA=
X-Received: by 2002:a2e:9b0f:: with SMTP id u15mr7866837lji.272.1589139521751;  Sun, 10 May 2020 12:38:41 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 10 May 2020 12:38:15 -0700
Message-ID: 
To: Mike Jones 
Cc: Torsten Lodderstedt ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b14fd605a55060d1"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 May 2020 19:38:59 -0000

--000000000000b14fd605a55060d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
2.0 was voluntary.

Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones  wrote:

> I agree with actively maintaining and improving the OAuth 2.0 specs by
> adding enhancements that are voluntary to use.  I=E2=80=99ve worked on ma=
ny such
> improvements, including Dynamic Client Registration, Authorization
> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
> etc.  The issue that=E2=80=99s the subject is the current discussion is w=
hether to
> make use of another enhancement, PKCE, mandatory in cases where it=E2=80=
=99s
> actually not needed, rather than making its use voluntary like the other
> enhancements, which I certainly support.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Torsten Lodderstedt 
> *Sent:* Sunday, May 10, 2020 3:15 AM
> *To:* Mike Jones 
> *Cc:* Daniel Fett ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> Hi Mike,
>
>
>
> Mike Jones  schrieb am Fr=
.
> 8. Mai 2020 um 18:55:
>
> OAuth 2.1 was supposed to not introduce breaking changes.
>
> I cannot remember the WG met that decision. Can you please refer to the
> respective thread?
>
>
>
> Requiring exact redirect URI matching is already a breaking change. Do yo=
u
> oppose against this as well?
>
>
>
>
>
> If you want to do that, please do it in TxAuth instead.
>
>
>
> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
> force any enhancements/improvements to go into TXAuth? This would cause
> huge migration efforts for existing deployments wanting to benefit from
> those enhancements.
>
>
>
> I think existing deployments are better served by actively maintaining an=
d
> evolving the 2.x line. For example, PAR and RAR are attempts to improve
> OAuth 2.x and make it usable for new use cases. That=E2=80=99s better pro=
tection of
> existing investments than sending them of to TXAuth.
>
> Kind regards,
>
> Torsten.
>
>
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Daniel Fett
> *Sent:* Thursday, May 7, 2020 11:50 PM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
>
>
> +1 to all what Aaron said. Thanks for pointing this out!
>
>
>
> We need to address this in the security BCP and this will be a normative
> change that affects OpenID Connect Core (just as our current recommendati=
on
> on the usage of nonce).
>
>
>
> We would then have:
>
>
>
> - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE=
,
> except if you are a public client, then you still need PKCE.
>
> - use state, except if you use PKCE, then you don't need state.
>
>
>
> I think there are very good reasons to simplify this down to
>
>
>
> - use PKCE
>
> - you may or may not use state
>
>
>
> First and foremost, not many people will understand why there are cases
> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
> understanding *why* you have to do something is key to compliance. The
> short version "PKCE protects the code; there is a specific case where it =
is
> not needed, but its better to use it all the time" is easy to understand.
> We will not see many implementations following the long version above
> correctly.
>
>
>
> Second, we dramatically reduce technical complexity by reducing cases tha=
t
> need to be handled. We reduce correctness and compliance testing complexi=
ty
> in the same way. We reduce the cost of security analysis, which scales
> really badly to more cases.
>
>
>
> And finally, using nonce to protect against code injection is less robust
> than PKCE. AS have a better track record than clients when it comes to
> correctly implementing security mechanisms.
>
>
>
> Yes, this will make a number of implementations non-spec-compliant, but I
> do not think that this is a huge problem. Software needs to adapt all the
> time and a software that has not been changed in a while is probably not
> one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will g=
et
> there.
>
>
>
> -Daniel
>
>
>
>
>
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>
> Backing up a step or two, there's another point here that I think has bee=
n
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE a=
s
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP fo=
r
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is bes=
t
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence hav=
e
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifie=
r
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> =E1=90=A7
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
=E1=90=A7

--000000000000b14fd605a55060d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Mike, I would consider upgrading to OA=
uth 2.1 to be voluntary, just as the other extensions. Similarly, OAuth 1.0=
 deployments upgrading to OAuth 2.0 was voluntary.=C2=A0

Would you clarify why you think upgrading=C2=A0to OAuth 2.1 would be manda=
tory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones <M=
ichael.Jones=3D40microsof=
t.com@dmarc.ietf.org> wrote:











I agree with acti=
vely maintaining and improving the OAuth 2.0 specs by adding enhancements t=
hat are voluntary to use.=C2=A0 I=E2=80=99ve worked on many such improvemen=
ts, including Dynamic Client Registration, Authorization
 Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR, =
etc.=C2=A0 The issue that=E2=80=99s the subject is the current discussion i=
s whether to make use of another enhancement, PKCE, mandatory in cases wher=
e it=E2=80=99s actually not needed, rather than making
 its use voluntary like the other enhancements, which I certainly support.<=
u>


=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>




From: Torsten Lodderstedt <torsten=3D40lodderst=
edt.net@dmarc.ietf.org>


Sent: Sunday, May 10, 2020 3:15 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org

Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?<=
u>




=C2=A0






Hi Mike,








=C2=A0






Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.o=
rg> schrieb am Fr. 8. Mai 2020 um 18:55:










OAuth 2.1 was sup=
posed to not introduce breaking changes.=C2=A0










I cannot remember the WG met that decision. Can you =
please refer to the respective thread?=C2=A0






=C2=A0






Requiring exact redirect URI matching is already a b=
reaking change. Do you oppose against this as well?






=C2=A0






=C2=A0










If you want to do=
 that, please do it in TxAuth instead.










=C2=A0






Interesting statement. Does it mean you want to cons=
erve OAuth 2.0 and force any enhancements/improvements to go into TXAuth? T=
his would cause huge migration efforts for existing deployments wanting to =
benefit from those enhancements.






=C2=A0






I think existing deployments are better served by ac=
tively maintaining and evolving the 2.x line. For example, PAR and RAR are =
attempts to improve OAuth 2.x and make it usable for new use cases. That=E2=
=80=99s better protection of existing investments
 than sending them of to TXAuth.






Kind regards,






Torsten.






=C2=A0










=C2=A0<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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<=
/u>






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Daniel Fett

Sent: Thursday, May 7, 2020 11:50 PM

To: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?






=C2=A0




+1 to all what Aaron said. Thanks for pointing this =
out!






=C2=A0






We need to address this in the security BCP and this=
 will be a normative change that affects OpenID Connect Core (just as our c=
urrent recommendation on the usage of nonce).






=C2=A0






We would then have:






=C2=A0






- use PKCE, except if you use OIDC with a nonce, the=
n you don't need PKCE, except if you are a public client, then you stil=
l need PKCE.






- use state, except if you use PKCE, then you don=
9;t need state.






=C2=A0






I think there are very good reasons to simplify this=
 down to







=C2=A0






- use PKCE






- you may or may not use state






=C2=A0






First and foremost, not many people will understand =
why there are cases when the BCP/OAuth 2.1 mandate PKCE and some where they=
 don't. However, understanding
why you have to do something is key to compliance. The short version=
 "PKCE protects the code; there is a specific case where it is not nee=
ded, but its better to use it all the time" is easy to understand. We =
will not see many implementations following
 the long version above correctly.






=C2=A0






Second, we dramatically reduce technical complexity =
by reducing cases that need to be handled. We reduce correctness and compli=
ance testing complexity in the same way. We reduce
 the cost of security analysis, which scales really badly to more cases.=







=C2=A0






And finally, using nonce to protect against code inj=
ection is less robust than PKCE. AS have a better track record than clients=
 when it comes to correctly implementing security
 mechanisms. 






=C2=A0






Yes, this will make a number of implementations non-=
spec-compliant, but I do not think that this is a huge problem. Software ne=
eds to adapt all the time and a software that has
 not been changed in a while is probably not one you would want to use anyw=
ay. We are setting a new goal for implementations to meet and eventually, m=
aintained implementations will get there.






=C2=A0






-Daniel






=C2=A0






=C2=A0






Am 08.05.20 um 01:38 schrieb Aaron Parecki:










Backing up a step or two, there's another point =
here that I think has been missed in these discussions.





=C2=A0






PKCE solves two problems: stolen authorization codes=
 for public clients, and authorization code injection for all clients. We&#=
39;ve only been talking about authorization code injection
 on the list so far. The quoted section of the security BCP (4.5.3) which s=
ays clients can do PKCE or use the nonce, is only talking about preventing =
authorization code injection.






=C2=A0






The nonce parameter solves authorization code inject=
ion if the client requests an ID token. Public clients using the nonce para=
meter are still susceptible to stolen authorization
 codes so they still need to do PKCE as well.






=C2=A0






The only case where OpenID Connect clients don't=
 benefit from PKCE is if they are also confidential clients. Public client =
OIDC clients still need to do PKCE even if they check
 the nonce.






=C2=A0






OpenID Connect servers working with confidential cli=
ents still benefit from PKCE because they can then enforce the authorizatio=
n code injection protection server-side=C2=A0rather=C2=A0than
 cross their fingers that clients implemented the nonce check properly.<=
/u>






=C2=A0






I really don't think it's worth the amount o=
f explanation this will take in the future to write an exception into OAuth=
 2.1 or the Security BCP for only some types of OpenID Connect
 clients when all clients would benefit from PKCE anyway.






=C2=A0






Aaron






=C2=A0








=C2=A0




=C2=A0






On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:










Hello!





=C2=A0






We would like to have PKCE be a MUST in OAuth 2.1 co=
de flows. This is best practice for OAuth 2.0. It is not common in OpenID C=
onnect servers as the nonce solves some of the issues
 that PKCE protects against. We think that most OpenID Connect implementati=
ons also support OAuth 2.0, and hence=C2=A0have support for PKCE if followi=
ng best practices.






=C2=A0






The advantages or requiring PKCE are:<=
/p>





=C2=A0






- a simpler programming model across all OAuth appli=
cations and profiles as they all use PKCE






=C2=A0






- reduced attack surface when using=C2=A0 S256 as a =
fingerprint of the verifier is sent through the browser instead of the clea=
r text value






=C2=A0






- enforcement by AS not client - makes it easier to =
handle for client developers and AS can ensure the check is conducted






=C2=A0






What are disadvantages besides the potential impact =
to OpenID Connect deployments? How significant is that impact?






=C2=A0






Dick, Aaron, and Torsten






=C2=A0










=E1=90=A7










=C2=A0

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=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